Trabajando con Git

Anotaciones para ayudarme a migrar de Subversion a Git. La intención es documentar los flujos básicos de trabajo con Git, y anotar las principales diferencias de concepto que voy encontrando.

Mi uso es para un solo desarrollador en multiples ordenadores. Es una configuracion muy sencilla (para lo que Git es capaz de hacer).

Asunciones:

• Servidor Git: aws.luisantolin.com
• Usuario Git con intercambio de claves SSH ya configurado: git
• Una sola rama, la de por defecto: master
• Una solo repositorio remoto por proyecto, el de por defecto: origin
• Nombre de proyecto: proyecto

Proyecto nuevo

Creando un proyecto nuevo. Git usa un repositorio por proyecto.

En el servidor

PROYECTO="proyecto" ; ssh git@aws.luisantolin.com "cd /var/git && mkdir \"${PROYECTO}\".git && cd \"${PROYECTO}\".git && git init --bare"

Listo, tenemos un repositorio vacio y listo para recibir datos.

En el cliente

cd <directorio raiz del proyecto>
git init .
git add -A
git commit -m "Initial commit. Everything was in a dot." 
git remote add origin git@aws.luisantolin.com:/var/git/<nombreproyecto>.git
git push origin master
git push --set-upstream origin master  

Listo, tenemos nuestro proyecto local enviado al servidor.

En otro cliente

cd <donde queramos que se cree la raiz de nuestro nuevo proyecto>
git clone git@aws.luisantolin.com:/var/git/<nombredeproyecto>.git
cd proyecto

Listo, ya podemos trabajar en este otro cliente.

Trabajo diario

1. Traemos la ultima version del repositorio: git fetch
2. Vemos los cambios: git diff master origin/master
3. Incorporamos los cambios: git merge origin/master
4. Hacemos nuestros cambios
5. Añadimos los ficheros cambiados al "staging area": git add -A
6. Hacemos el commit de los cambios en el repositorio local: git commit -m "descripcion de commit"
7. Enviamos los cambios al servidor: git push

Nota: fetch y merge se pueden hacer juntos con git pull origin master

Y vuelta a empezar :)

Diferencias con Subversion

Tropezaré en estas mil veces.

Lo que en Subversion era un solo paso (commit) aqui son tres: add, commit y push.

Git tiene el concepto de "staging area", un area intermedia donde tengo que ir anotando los cambios explicitamente antes de hacer commit. De modo que desde que yo cambio un fichero hasta que esta disponible en el repositorio son 3 pasos:

1. add lo anota como cambiado en la "staging area", totalmente local
2. commit agrupa todos los cambios de la "staging area" y les da un ID y una descripcion, ¡aun todo local!
3. push envia el commit al repositorio remoto

En Git todo son ramas, fetch se trae los cambios a lo que llama "rama remota" dentro del repositorio local

Al traer cambios del repositorio también hay mas pasos que en Subversion. Aqui el concepto nuevo (y confuso en mi modesta opinión) es que se trae los cambios a una rama remota local, nombre confuso donde los haya, quizá queda mas claro decir una rama remota del repositorio local. Es decir que en el repositorio local tenemos dos tipos de ramas, las locales, y una copia de las remotas (se ven todas con git branch -a.

1. fetch trae los cambios desde el repositorio a una rama remota de nuestro repositorio local.
2. merge incorpora los cambios, de cualquier rama a cualquier rama, en este caso de la remota a la local