Ésta seguramente acabará siendo una entrada que iré modificando una y otra vez, ya que lleva en borradores más de un año, y desde entonces, he entrado decenas de veces a editar y a ampliar el contenido.

En fin, git es un sistema de control de versiones open source y distribuido, que cambia el concepto de trabajo de los antiguos sistemas de control de versiones tipo «subversion». Git mantiene una copia completa de todo el repositorio, en cada uno de los ordenadores de trabajo, de tal manera que el programador siempre trabaja en local con su copia completa, lo cual le permite trabajar sin conexión o desde cualquier PC con acceso al repositorio de git (lo cual le permitiría clonar de nuevo el repositorio y continuar trabajando en local en el nuevo PC).

Si estás empezando con git, mírate bitbucket, que quizá te interese, y planteate usar algún cliente Git, como SourceTree. Si eres más de Linux y terminal, entonces quizá ésto te interese.

Git clone

Para copiar en local el repositorio entero de git, bastará con ejecutar git clone, seguido del fichero git con el repositorio a clonar. Por ejemplo:

[root@adripc]# git clone https://[email protected]/miproyecto/mirepo.git

El git clone, habitualmente, creará en el directorio local en el que estamos ubicados, un nuevo directorio que contendrá todo el árbol con el repositorio git. Hará un clonado en local, en toda regla. También podemos usar git clone para clonar nuestro repositorio local a un segundo repositorio local.

Git pull

Podemos actualizar nuestro repositorio local con los nuevos cambios que los compañeros hayan subido, símplemente ejecutando, desde la raíz del repositorio:

[root@adripc]# git pull

Es una buena idea, antes de subir nuestros cambios locales, hacer un git pull, para evitar problemas subiendo ficheros. Si nosotros editamos la misma línea del mismo fichero que otro compañero ha editado ya (y subido al repositorio), nos dará un error al subir nuestros cambios. Para ello, es mejor hacer primero un git pull, lo cual dará una advertencia de CONFLICTO, indicando el fichero con el conflicto, y lo modificará con un comentario duplicando el contenido conflictivo, para que nosotros resolvamos el conflicto (en caso de que no pueda resolverlo el propio git de forma automática).

Git add

Para actualizar nuestra branch local,

[root@adripc]# git add <nombre fichero>

o

[root@adripc]# git add <nombre directorio>

Git add lo que hará será indicarle a git que ese fichero o ese directorio deberá incluirse en el siguiente «commit», pero no se actualizará.

También podemos usar, si lo preferimos, los siguientes atajos (Fuente):

• git add -A stages All
• git add . stages new and modified, without deleted
• git add -u stages modified and deleted, without new

Git commit

Cuando estemos listos para subir los cambios, ejecutaremos:

[root@adripc]# git commit -m «Mensaje»

El «Mensaje» de git commit será un comentario que describirá los cambios que se están subiendo al repositorio, de cara a posteriormente tener un control. Al hacer un commit, se grabará el usuario que ha realizado el commit. Se puede definir el nombre del usuario y su mail (ésto bastará con ejecutarlo una única vez):

[root@adripc]# git config –global user.name «Adri»
[root@adripc]# git config –global user.email [email protected]

Ahora sí, podemos ejecutar el git push.

Trabajando con diferentes branches

Git branch

Un proyecto puede tener diferentes branches. Podemos ver en qué branch estamos trabajando, ejecutando:

[root@adripc]# git branch
* master

El asterísco nos indicará la branch que estamos usando. Con la opción «-a» (all) veremos todas las ramas, tanto locales como remotas. Con la opción «-r» veremos únicamente las remotas:

[root@adripc]# git branch -r
origin/HEAD -> origin/master
origin/master
origin/new_database

Si queremos, por ejemplo, descargar la branch «new_database» y empezar a trabajar con ella, en local, primero deberemos actualizar nuestro índice local (actualiza el índice de nuestro repositorio pero sin actualizar los cambios en código):

[root@adripc]# git fetch origin

A continuación podremos hacer un checkout de la rama remota:

[root@adripc]# git checkout -b new_database origin/new_database
Branch new_database set up to track remote branch new_database from origin.
Switched to a new branch ‘new_database‘

También podemos crear nuevas branches locales con:

[root@adripc]# git branch nuevabranch

Podremos cambiar entre branches locales con:

[root@adripc]# git checkout nuevabranch

Si además queremos pushear la nueva branch que acabamos de crear, al repositorio remoto, para que también ahí esté la nueva branch creada en local, primero deberemos asegurarnos de que efectivamente estamos en la nueva branch local, para posteriormente pushear.

[root@adripc]# git branch
* nuevabranch
master
//Aquí irían los git add y git commit previos a pushear los cambios
[root@adripc] git push origin nuevabranch

Git stash

Es posible que tengamos un error en el punto anterior, si por ejemplo estábamos trabajando con nuestra branch local y no habíamos pusheado los cambios. Si igualmente nos interesa cambiar de branch de trabajo dejando a medias nuestra anterior branch, será necesario ejecutar «git stash»:

[root@adripc]# git stash

Podremos ver cómo hemos cambiado de rama de trabajo, ejecutando de nuevo:

[root@adripc]# git branch
master
* new_database

.gitignore

.gitignore es un fichero en el cual podremos indicar qué directorios o ficheros queremos dejar fuera de la sincronización, es decir, serán ficheros y/o directorios que no se actualizarán al hacer push/pull. Se suelen poner aquí ficheros de log, ficherlos de configuración locales, o directorios temporales.

Lo importante es notar que se debería crear el fichero gitignore con los directorios/ficheros a ignorar, antes de hacer el primer commit con ellos, pues una vez git empiece a trackear estos ficheros/directorios, no hará caso al gitignore aun cuando estos ficheros/directorios estén en él. [Fuente]. Si quisiéramos modificar el .gitignore una vez el fichero o directorio está trackeado por git, deberemos eliminarlo del índice de git y volver a hacer un commit:

[root@adripc]# git rm –cached logs/myproject.log
[root@adripc]# git commit -m «Commiting logs to ignore them»

Git log / Git checkout / Git revert / Git reset: Revertir cambios

Con «git log» veremos los commits que se han hecho al repositorio, ordenados de más reciente a más antiguo. Cada commit tendrá un identificador que nos servirá para referirnos a él, con checkout o revert, según necesitemos [Fuente].

Por ejemplo, con git log podemos ver que queremos revertir los cambios y descartarlos, para volver al commit e63e0a715394abd06b82ff9acbdd73977a68930d… Bastará con ejecutar git reset para descartar los cambios y volver a la versión de código commiteada que nos interesa [Fuente]:

[root@adripc]# git reset –hard e63e0a715394abd06b82ff9acbdd73977a68930d

Ver y descartar diferencias

Si en nuestra branch local activa (sea la que sea) tenemos uno o varios ficheros modificados respecto a la branch «master» (por ejemplo), podemos ver las diferencias ejecutando:

[root@adripc]# git diff origin/master protected/views/user/file.php

Si lo deseamos, podemos descartar los cambios de ese fichero con:

[root@adripc]# git checkout — protected/views/user/file.php

Fuentes:

https://www.youtube.com/watch?v=ZDR433b0HJY
https://www.youtube.com/watch?v=iiIJYdTPJOo
https://confluence.atlassian.com/display/STASH/Basic+Git+commands
http://es.gitready.com/intermediate/2009/02/13/list-remote-branches.html