Y aunque con retraso (nada menos que tres semanas), volvemos con la última entrada sobre este tutorial en dos capítulos, perteneciente a la serie #AskToPablo. En la primera hablamos de los fundamentos de GIT y su configuración inicial, y en esta vamos a hablar de los comandos más usados para comunicarnos con el repositorio, así como la gestión de las diferentes ramas que tengamos en un proyecto (dar las gracias a Pablo Esteban, por su petición vía correo).
Crear una rama de Git
Ya sabemos que Git nos permite tener un repositorio de control de versiones, de tal forma que podemos trabajar en colaborativo sin miedo a problemas de actualización y versión, o volver atrás cuando queramos.
Esto es así porque Git guarda cada nueva versión como un slapshot, no de forma incremental. Por ello, cada commit que subimos al servidor, cuenta con una copia real de todo el directorio del proyecto (blobs), más un archivo de metadatos, todo albergado en una rama superior del árbol del proyecto.
El método para guardar una nueva versión es siempre el mismo, e indiferente del SO con el que trabajemos:
- Con la consola de comandos (terminal, shell,..) navegamos hasta el directorio raíz de nuestro proyecto:
$ cd ..
- Una vez en él, generamos el subidirectorio .git, oculto, y necesario para albergar la información interna del repositorio.
$ git init
- Con el subdirectorio creado, le decimos qué elementos forman parte del proyecto (normalmente todo el directorio):
$ git add *
- Preparamos los archivos para subirlos (
staged):
$ git add .
- En este punto, es interesante asegurarse de que no hemos cometido ningún error, por lo que os dejo dos comandos. El primero (status) te informa del estado de los archivos en referencia a la última versión de la rama del repositorio, y el segundo (diff) compara los archivos con los que ya están preparados (por si nos dejamos alguno).
$ git status
$ git diff
- Añadimos un comentario (interesante que sea descriptivo de los cambios de esta versión respecto a la anterior, de cara a navegar entre ramas de forma más eficiente) y confirmamos la nueva versión para subir.
$ git commit -m "comentario"
- Le indicamos la ruta en la que tenemos que subirlo. En este caso, os pongo un ejemplo subiéndolo a mi cuenta de GitHub (hay que elegir una de las dos opciones:
$ git remote add origin [email protected]:PabloYglesias/projectname.git
$ git remote set-url https://github.com/PabloYglesias/projectname
En caso de contar con usuario y contraseña, normalmente te pedirá en este punto que insertes la contraseña.
- Lo subimos:
$ git push origin master
Existen muchos más comandos que pueden ser interesantes (como el de crear etiquetas, o clonar versiones), pero por no recargar la entrada, os dejo el enlace a la wiki de Git (ES).
Control de Ramas
Como ya hemos dicho, Git permite ordenar las versiones como un árbol, de tal manera que en cualquier momento podemos comenzar una nueva rama, o volver a alguna anterior. Esto es terriblemente interesante para proyectos complejos, pudiendo dedicar una rama a cada error o nueva implementación que se quiera desarrollar, de tal manera que si al final resulta un fracaso, la dejamos abandonada sin afectar al resto del proyecto.
En caso de que no informemos expresamente al gestor que queremos trabajar en otra rama, por defecto Git genera una rama «master«, que irá aumentando de posición conforme creemos nuevas confirmaciones, situándose siempre en la última.
Si deseamos crear una nueva rama, bastaría con informar de ello mediante el comando branch:
$ git branch testing
Puesto que no hemos definido un punto de versión anterior, testing se crea en el mismo punto que master
Hay otro concepto vital para comprender el funcionamiento de las ramas de Git, y este es HEAD, otro puntero que apunta siempre al puntero de la rama que estamos usando. Puesto que lo único que hemos hecho en el punto anterior es crear una nueva rama testing, seguiremos apuntando a master.
Para cambiar de rama, bastaría con apuntar HEAD a otra rama, en este caso testing:
$ git checkout testing
Existe un atajo para crear nueva rama y apuntar a ella, que no es más que:
$ git checkout -b testing
En este caso, tanto testing como master están apuntando a la misma versión, pero si ahora confirmáramos una nueva versión, master se quedaría en f30ab, y tanto testing como HEAD se moverían a la nueva.
Si ahora volviésemos a apuntar HEAD a master, lo que conseguiríamos es revertir los cambios, dejándolos tal y como están en f30ab, y si desde aquí, hiciéramos un nuevo commit, obtendríamos una ramificación del proyecto.
Fusión de ramas
Y ahora estaréis pensando:
Todo muy bonito, ¿pero de qué me sirve trabajar en otra rama sobre un problema en particular si una vez lo tenga resuelto me va a tocar implementarlo en la rama raíz (master)?
Pues tiene fácil respuesta: Mergue.
El comando mergue nos permite fusionar ramas, de tal manera que una vez tengamos una implementación funcionando, podemos incluirla en la rama raíz y seguir a partir de ahí como el resto del equipo de trabajo. Además, es tan sencillo como posicionarnos en la rama a la que queremos anexionarnos, e informarle de qué otra rama tomará para la fusión.
$ git checkout master
$ git merge testing
Ahora, tanto master como testing apuntarán a una misma versión (la rama testing, con sus sucesivos commit, seguirá existiendo), uniendo nuevamente las ramas.
Y con esto doy fin a este repaso de Git, una herramienta muy pero que muy útil para el trabajo colaborativo, y para cualquier proyecto de una complejidad considerable.
Como ya sabéis, podéis proponer nuevos temas sobre los que hablar en los canales de comunicación siguientes:
- Hashtag #AskToPablo en Twitter, o directamente mencionándome (@PYDotCom).
- Mensaje privado o mención a mi cuenta de Google Plus.
- Email desde la página de Contacto.
- Mensaje privado en la página de Facebook.
Intentad dejar esta entrada para consultas de la propia entrada. Muchas gracias, ¡y seguimos en contacto!
