Ramificación de un proyecto en Git
Cuando trabajamos en un proyecto en Git, podemos crear varias ramas independientes unas de otras, de manera que, por ejemplo, un equipo podría trabajar en corregir errores existentes mientras que otro equipo se encargaría de añadir nuevas funcionalidades sin tener que compartir los mismos archivos. Cada equipo trabajaría en su propia rama del proyecto. En esta entrada no hablaré de cómo trabajar varios equipos sobre el mismo proyecto, eso lo dej para otro día. Hoy me centraré en el trabajo con ramas.
Creando varias ramas
Comienzo creando un nuevo proyecto y creando un repositorio Git específico para él como ya expliqué en mi primera entrada. Y le añado un par de versiones:
Lo primero que nos encontramos en el repositorio Git, ya sea en el historial o en el panel Git, es la rama en la que estamos trabajando:
Crear una rama es tan simple como pulsar en el signo "+" del panel Git. Cada nueva rama hereda todas las versiones (commits) de la rama que indiquemos como Source:
Ahora puedo modificar un fichero y crear una versión, exclusiva de la rama con la que esté trabajando:
Fusionando ramas.
Normalmente las ramas se crean con el objetivo de terminan fusionando sus cambios con la rama principal:
En este caso era fácil porque los cambios de "Experimental" no tenían conflictos con "Master". ¿Qué ocurriría si "Master" y "Experimental" tuvieran versiones distintas del mismo archivo?
La operación de Merge utilizará la versión más moderna (esto hay que tenerlo en cuenta a la hora de mezclar, porque podríamos terminar perdiendo los cambios de la rama "donante" si la rama "receptora" es más moderna). Pero si las dos ramas son contemporáneas la operación de mezcla dará un error y la única manera de continuar será resolviendolo a mano:
Los signos "<<<<<<"; "=====" y ">>>>>>" forman parte de la sintaxis de Git. Son marcadores para que sepamos donde comienzan y terminan los conflictos y de donde provienen. PAra resolverlos tenemos que borrar lo que no queramos conservar, incluidos todos los indicadores, y dejar en el fichero solo lo que queramos quedarnos. Hasta que no borremos TODOS los marcadores el sistema seguirá marcandonos que existe un conflicto. Una vez resuelto el conflicto solo quedaría hacer un commit a la rama "receptora" para terminar la fusión.
Una rama donante, una vez que se fusiona con la receptora, puede borrarse (no tiene sentido conservarla, sus cambios ya han sido transferidos). Para borrar una rama, simplemente pulsamos en el símbolo "-" del panel Git.
Para terminar de sacarle todo el partido a Git solo falta saber como usarlo para que trabajen sobre el mismo repositorio varios equipos. Pero eso es otra historia que contaré en mi siguiente entrada.
