Paso a paso, la creación de un proyecto remoto en GitHub.

• Partimos de un proyecto java recién creado en Eclipse …

En este punto, podemos trabajar con él de forma local sin ningún tipo de control de los
avances que estamos haciendo en él. A lo sumo, podemos hacer copias de vez en cuando de la
carpeta del proyecto.
Para pequeños proyectos es más que suficiente, pero si tu proyecto crece y crece, se irán
acumulando un montón de carpetas y será difícil y tedioso ir mirando en cada una de ella para ver
donde hiciste tal cambio que ahora choca con lo nuevo que has añadido.
Por estos problemas y otros mucho más complicados como trabajar en equipo sin pisarse los
trabajos unos a otros, el trabajar sin controlar no sale rentable.

De ahí de desarrolló lo siguiente:

Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los
elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un
producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o
modificación.
El sistema de control de versiones puede realizarse de forma manual, o con herramientas
que faciliten esta gestión dando lugar a los llamados sistemas de control de versiones o VCS (del
inglés Version Control System). Estos sistemas facilitan la administración de las distintas versiones
de cada producto desarrollado.
Ejemplos de este tipo de herramientas son entre otros: CVS, Subversion, SourceSafe, ClearCase,
Darcs, Bazaar, Plastic SCM, Git, SCCS, Mercurial, Perforce, Fossil SCM, Team Foundation Server.

El control de versiones se realiza principalmente en la industria informática para controlar las

distintas versiones del código fuente dando lugar a los sistemas de control de código fuente o SCM
(siglas del inglés Source Code Management). Sin embargo, los mismos conceptos son aplicables a
otros ámbitos como en trabajo de oficina tales como documentos, imágenes, sitios web, etc.
 Forma de trabajo con GIT:

EN EL EQUIPO LOCAL:

checkout reset

almacén historia
trabajo

add commit

(Working Directory) (Staging area) ( git directory (repository))

Directorio de trabajo Área de seguimiento Repositorio local de git.

Este es el directorio de Este es el directorio oculto de “Git”, donde se realiza el

trabajo, donde creamos y seguimiento de los ficheros que queramos y guarda todas
modificamos los archivos de las instantáneas (para seguir la historia de como
nuestro proyecto. evoluciona).
También aquí, es donde copiamos en el ordenador
No hay nada de especial, cuando descargamos …
sólo donde «guardamos» un repositorio remoto → a nuestro repositorio local.
Primeros Pasos

El modo de proceder desde consola es igual que desde los IDE gráficos.
Hay que recordar que cada instrucción en consola le corresponderá una acción de ratón en tu IDE.
La forma rutinaria sería:
(Desde el equipo local)

1º.- Se crea un proyecto nuevo, que va emparejada la creación de una carpeta donde se guardará
dicho proyecto, a mano o con el IDE que desees.

2º.- Dentro de la carpeta del proyecto, se ejecuta:

git init

Creando así el repositorio oculto Git donde se situaría el “Staging area” o de seguimiento y
el git repository donde se guarda el historial de instantáneas (suele llamarse .git).

3º.- Cada vez que consideremos oportuno, al ir añadiendo nuevas cosas a nuestro proyecto,
podemos guardar una instantánea.
Esto se hace en dos pasos:
(primero)
Se debe indicar a Git que queremos “fotografiar”, indicándolo en el área de seguimiento ( Staging)
git add (nombre de fichero o ficheros que deseamos controlar)
(segundo)
Una vez indicado a quién seguimos, podemos hacerlo poco a poco, retocando ficheros y
añadiéndolos al Staging uno a uno.
Finalmente tomamos la instantánea con …
git commit

Este es el proceso rutinario, o bien a mano, o bien con el IDE de turno, que se realiza según
avancemos en nuestro proyecto. Según vamos construyendo el código, cuando consideremos un
avance o una nueva característica repetimos add y después commit, creando una historia que se va
almacenando localmente en el repositorio oculto .git

Nota:
No debe seleccionarse todos los archivos del proyecto a saco, ya que muchos son o bien ejecutable
o bien de ayuda al sistema operativo de turno.
Por ello, al incluir cuales seguir con git add o de forma gráfica con el típico recuadro de selección
hay que asegurarse de no incluir nada que no sea el código fuente (o ficheros de configuración),
excluyendo todo lo que crea el sistema el sólito, o los ejecutables que se reconstruyen simplemente
al compilar.

Observación:
Esto es sólo una pincelada del trabajo en local con git a fuerza de comandos. Según el caso puede
ser útil esa forma de proceder, pero lo usual es con ayuda de un interfaz gráfico concreto o con el
mismo IDE de trabajo.
Hay muy buenos manuales de su uso en comandos, incluso en la página de Git
https://git-scm.com/doc
El objetivo de este manual es verlo paso a paso con el IDE Eclipse.
CON EL EQUIPO LOCAL, TRABAJADO EN REMOTO:

Para poder trabajar con un sistema como Git, en remoto, hay que entender su filosofía de
trabajo. Como indiqué, puedes trabajar todo un proyecto en local desde tu casa o trabajo sin tener
que usar nada en remoto, ya que Git trabaja con todo el árbol del proyecto en local.
Luego cuando quieres o tienes por motivos laborales trabajar en remoto con un equipo, con Git no
hay problemas, siempre que sepas donde estas.
Ahora hay más de un ordenador (programador) que trabaja sobre el proyecto. Ésto obliga a crear en
la nube un servicio Git que gestionará el repositorio central del proyecto.

Hay varios escenarios posibles:

a) No se inicia un repositorio local creándolo, sino se crea en remoto y éste suele ser clonado
en cada uno de los equipos que trabajen en remoto.
b) Se crea el proyecto en uno de los equipos remotos, y este lo “clona” al repositorio. Y desde
allí los demás podrán clonarlo y trabajar en sus equipos.
( El ejemplo que mostraré arranca así )

(Podría ser GitHub u

otro servidor git remoto)
Repositorio
Central
en Remoto

Pull
Push

Push Pull

Push Pull

Equipo local 3
Equipo local 1

Equipo local 2
Observación: Un error de percepción típico que sucede es considerar al repositorio en remoto, en
nuestro caso, en GitHub a un servidor estándar donde hay una “especie” de base de datos que lleva
el control. Pero en realidad el servidor remoto se comporta como el local, por lo tanto tenemos
tenemos en remoto el mismo proceso de:
“crear” → “pasar al monitoreo: Staging” → “commit apareciendo la instantánea en el repositorio”
Luego, cuando trabajamos en equipos remotos, tenemos que tener en mente que los tres estados
están tanto en cada uno de los repositorios locales como en el central de GitHub.

La idea del proceso que voy a presentar va a seguir el escenario b), o sea:
1. Creamos en local el proyecto.
2. Creamos el repositorio local de Git.
3. Hacer un par de “commits”, para ver como lo realiza Eclipse.
4. Crear un repositorio vacío en GitHub.
5. Clonar el repositorio local al remoto de GitHub.
6. Desde GitHub, añadir dos ficheros: el Readme y la Licencia.
7. Como a cambiado el repositorio remoto (al añadir esos ficheros), hay que actualizar el
repositorio local.
8. Comentarios de los modos de trabajar una vez de forma corriente.

Recapitulemos, en la página 1, ya hemos creado un proyecto en java llamado “JavaTips”, que sólo
sale una ventana vacía (al menos compila).

Ahora toca crear un repositorio local oculto .git

-Pulsando con el botón derecho sobre el proyecto, en la opción “Team” → “Share Project”

-Aquí nos pregunta donde crear el repositorio, nosotros elegiremos crearlo dentro de la carpeta del
propio proyecto, habilitando la pestaña …

-Un vez marcada (aparece un pequeño aviso), hay que dar a “Create Repositiry” para poder dar a
“Finish”.
Ya se ha creado el repositorio local.

Se puede ver que a cambiado el icono del

proyecto, aparece un pequeño tambor indicando
que el proyecto además de estar en la carpeta propia
del proyecto, hay un directorio oculto donde
se gestionará las versiones del proyecto y se guardarán
las instantáneas que se vayan tomando.
-Ahora si se vuelve a ver el menú contextual del proyecto la opción “Team” ha cambiado y muestra
un variado numero de opciones para realizar las acciones típicas del control de versiones en nuestro
recién creado repositorio loca.
-Vamos a proceder a hacer el 1º commit:
menú contextual del proyecto la opción “Team” → “Commit…”

Sale una ventana de control “Git Staging”, donde podemos seleccionar a los ficheros que queremos
monitorear, pasándolo al “área de Staging” y posteriormente hacer el Commit.

-Ejecutar el comando git add, aquí equivale a los iconos (individual si se selecciona uno a
uno,
o éste si seleccionas a todos para monitorear.

-En este caso, seleccionamos todos ya que son ficheros de configuración y de código fuente.
Para terminar de tomar la 1ª instantánea, añadimos un comentario del cambio ocurrido que nos será
útil para localizar en la historia del proyecto cuando ocurrió.

-Pulsamos “Commit”

Y ya se ha
realizado la primera instantánea
(cerramos esa ventana).

Se pude ver en el árbol del proyecto

como han cambiado todos los iconos
de los elementos controlados
por nuestro repositorio local.
Ahora vamos a ver nuestro proyecto, con las ayudas visuales de Eclipse en interacción con git.
Cambiamos la perspectiva del IDE, desde el botón “Open Perspective” de la barra de botones o
desde el menú “Window” → “Perspective” → “Open Perspective” → “Other...”

Se selecciona “Git” y se pulsa en “Open”

para cambiar.

Aquí vemos las diferentes ventanas de control

de versiones como “Git Staging”
Y tocando nuestro repositorio, desplegamos
su estructura git.

Volvamos a la perspectiva estándar de

inicio se procede igual y se selecciona
“Java (default)”

Ya que vamos ha hacer unos cuantos cambios

en nuestro proyecto y de paso unas cuantas
instantáneas.
Le ponemos un título a la ventana principal.

Ahora procedemos como antes y desde el menú Team o desde realizamos el commit.
Añadimos el fichero que
ha cambiado con la cruz verde
y después de poner
un comentario
pulsamos en “Commit”

Saltamos a la perspectiva “Git”

Y teniendo seleccionado nuestro proyecto, pulsamos el “History”

Y vemos la historia de instantáneas que llevamos realizadas.

Volvemos a la perspectiva “Java (default)”, para realizamos una serie de cambios, necesarios y
típicos en cualquier proyecto. Esto nos sirve, volviendo a la perspectiva “Git”, mirando
el “History”, podemos ver como ha ido evolucionando el proyecto.

Ahora, después de estar trabajando un rato, antes de cerrar Eclipse, lo normal es subir
los cambios al repositorio remoto donde centralicemos nuestro proyecto, para trabajar en equipo o
nosotros mismos desde ordenadores distintos y trabajar siempre desde la última versión de él.
Como es la primera vez, primero tenemos que enlazar nuestro repositorio local con el
repositorio remoto. Nosotros trabajaremos con el servidor git de GitHub, para trabajar en remoto.
La empresa donde trabajemos igualmente puede trabajar con ese servidor en la nube, otro o un
servidor git propio de la empresa. El modo de proceder es el mismo, sólo que con la nueva
dirección de internet.

Nota: Como mi IDE Eclipse lo tengo enlazado con mi cuenta en GitHub, no necesitaré
identificarme para clonar mi repositorio local.
-Desde la perspectiva Git:

Pulsamos sobre “Remotes”,

y con su menú contextual, pulsamos en “Create Remote…”,
y en siguiente ventana damos a “Create”

--- ¡Un Alto en el camino! ---

 --- ¡Un Alto en el camino! ---
Observación:
¿Qué intentamos hacer? Estamos enlazando nuestro repositorio local a uno en GitHub.
* Uso GitHub, porque es un buen ejemplo se servicio git en la nube.
Para enlazar, primero debe existir algo en la nube donde apuntar, por lo tanto, hay que crear un
repositorio en GitHub vacío.
Nos logueamos en nuestra cuenta en GitHub y procedemos a hacerlo:

De la página web de GitHub,

seleccionamos SSH y copiamos
la dirección.

Ahora ya podemos dar a “Create”

Repito: Como mi IDE Eclipse lo tengo enlazado con mi cuenta en GitHub, no necesitaré
identificarme para clonar mi repositorio local.
Porque en el repositorio tengo mi clave pública “id_rsa.pub” subida a ni cuenta de GitHub.
Y con la dirección [email protected]:Sergioteacher/JavaTips.git
será suficiente para la comunicación …
Nos sale una ventana de configuración push al repositorio remoto.

Nos pide el URI, así que lo elegiremos pulsando “Change”

Saldría esta ventana, en principio, donde hay que poner la dirección git@…
con el protocolo ssh

*Pero si justo antes copiamos de la página web esa dirección, Eclipse se da cuenta de ello y auto-
completa todo.
Cancelando el enlace desde la perspectiva “Git”, y pasando a la usual “Java (default)”
Y desde el menú contextual del proyecto:
“Team” → “Push Branch ‘master’ ...” y sale auto-completado

Damos a “Preview >”

Seguimos damos a “Preview >”

Intenta realizar la conexión con el repositorio remoto,
y si lo detecta sólo queda dar a “Push”

Mostrando el proceso de clonado en remoto,

y la ventana de que ha concluido el Push.

Comprobamos actualizando la página web del repositorio remoto en GitHub, que se ha clonado el
proyecto

Lo aconsejable en todo repositorio público en GitHub, es añadir un fichero Readme que se usa para
indicar los objetivos del proyecto, para posibles colaboraciones en un futuro, y una licencia que
determine la disponibilidad de tu código.

Procedemos desde la misma página web de GitHub para crear los dos ficheros …
Una vez escrito algo descriptivo del
proyecto en el README.md
damos al “Commit changes...”

pasándolo al área de monitoreo y una vez

añadido el mensaje
procedemos a ejecutar el commit
dando al “Commit changes”

Quedando así la web.

Ahora toca la licencia:

Procedemos de forma análoga

usando las facilidades de GitHub
que nos permite elegir la licencia
que más se acerque a nuestros
objetivos,

Actualizado la página web vemos el aspecto estándar de los típicos proyectos en GitHub,
al menos, un inicio típico.
He realizado cambios en el proyecto directamente en la nube, porque he añadido un Reame y una
licencia, esta situación sería análoga a que desde otro ordenador vinculado a ese proyecto hubiera
echo cambios (nosotros mismos desde otro equipo) y los hubiera subido a la nube.
Luego antes de hacer cualquier cambio o evolución en nuestro proyecto tenemos que sincronizar
nuestro proyecto local con la nube.
Desde la perspectiva “Java (default)”, en el menú contextual del proyecto:
“Team” → “Synchronize Workspace”

Detectando dos ficheros para bajar, así que hacemos un Pull

descargando las actualizaciones,

se observa actualizado el árbol del proyecto,
esos dos ficheros.

También se ven los nuevos ficheros

en el repositorio local
desde la perspectiva “Git”
 Ahora estamos ya en una situación donde tenemos un proyecto tanto en local como en
remoto totalmente sincronizados.
Luego lo interesante es ver como se sigue con el trabajo rutinario, donde la idea es hacer algunos
cambios en el proyecto, e ir creando instantáneas (commits) según consideremos en nuestro
repositorio local, y al final del día (o el par de horas programando) actualizamos el repositorio
remoto haciendo un Push.

Voy a hacer un sólo cambio añadiendo un título en la ventana de la aplicación y voy a

subirlo a la nube con Push y después voy ha hacer dos cambios en local (dos commits) y haré otro
Push dejando los dos repositorios iguales.

1º retocamos añadiendo un título y hacemos un commit.

Después lo subo desde el menú contextual del proyecto:

“tema” → “Push Branch ‘master’...”

Pulsamos en “Preview >”, nos muestra la ventana de confirmación y pulsamos “Push”

Después se muestra una ventana con notificando el resultado del Push,

además se puede ver en la página web, que se ha actualizado.

Ahora realizo un par de cambios

(realizando dos commits en local),
y como termino por hoy,
lo sincronizo con otro Push.

“tema” → “Push Branch ‘master’...”

Lo confirmo y después muestra los resultados de hacer el Push a esos dos últimos commits.
También desde Eclipse se pueden ver todos los commits realizados, cambiado a la perspectiva “Git”
y seleccionando nuestro proyecto pulsamos en la pestaña “History”

Igualmente podemos ver los commits

desde la página web del repositorio remoto.

Tómese este pequeño manual como una

pequeña introducción al uso del IDE
Eclipse en el uso de repositorios git
tanto local como en remoto.