Cómo crear ramas en git

Detalles: 13 Marzo 2020

Supongamos que deseamos tener dos copias locales de un repositorio remoto sincronizadas a diferentes ramas. Por ejemplo una copia local sincronizada contra una rama"estable" (para mostrar la versión de una aplicación en producción) y otra sincronizada a una rama de desarrollo o inestable (para mostrar la versión de una aplicación en desarrollo o pruebas). Este artículo explica como crear, sincronizar y clonar ramas en git desde línea de comandos.

Partiendo de un repositorio que posee una única rama de desarrollo llamada "master", el objetivo es crear una rama estable (donde aplicar cambios estables a largo plazo y probados) y otra inestable o de desarrollo (donde avanzar con el desarrollo del proyecto sin alterar la rama estable en producción).

Antes de comenzar, veamos el estado de la copia local del repositorio.

Estado de una copia local

Para obtener información sobre la rama actual basta con recurrir al comando git status o git branch:

root@debian:/var/www/recoll-webui# git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

Mientras que git status muestra la rama actual en la primera línea de la salida, git branch lista todas las ramas marcando con asterisco la rama actual:

root@debian:/var/www/recoll-webui# git branch
* master

Se observa entonces que el repositorio tiene una única rama llamada "master" (rama por defecto al crear un repositorio con git).

Crear ramas

Para crear una nueva rama, ejecutar git branch pasando el nombre de la rama como parámetro. En el siguiente ejemplo se crean dos nuevas ramas, "estable" y "desarrollo":

root@debian:/var/www/recoll-webui# git branch estable
root@debian:/var/www/recoll-webui# git branch desarrollo

Ahora git branch muestra todas las ramas, resaltando con asterisco la rama "master":

root@debian:/var/www/recoll-webui# git branch
  desarrollo
  estable
* master

Cambiar de rama en una copia local

Supongamos que se desea mantener esta copia local como versión de producción. El siguiente paso consiste entonces en cambiar a la rama "estable". Para cambiar de rama se dispone del comando git checkout:

root@debian:/var/www/recoll-webui# git checkout estable
Switched to branch 'estable'

Ahora la copia local está sincronizada con la rama estable:

root@debian:/var/www/recoll-webui# git branch
  desarrollo
* estable
  master

En esta rama se subirán cambios estables una vez probados y verificados en la versión de desarrollo que estará sincronizada contra la rama "desarrollo". La idea es que el desarrollo (valga la redundancia) del proyecto avance en la rama "desarrollo" (inestable) mientras que la rama "estable" avance a largo plazo con cambios debidamente testeados.

root@debian:/var/www/recoll-webui# git status
On branch estable
nothing to commit, working tree clean

Enviar cambios al repositorio remoto

Habiendo creado nuevas ramas en la copia local, es deseable subirlas al repositorio. Para enviar estas nuevas ramas al remoto, es necesario hacer un checkout (cambiar de rama) y push (subir cambios) de cada una por separado.

Primero la rama "estable", a la cual se ha cambiado en el paso anterior:

root@debian:/var/www/recoll-webui# git push -u origin estable
Total 0 (delta 0), reused 0 (delta 0)
remote: 
remote: To create a merge request for estable, visit:
remote:   https://gitlab.linuxito.com/emiliano/recoll-webui/merge_requests/new?merge_request%5Bsource_branch%5D=estable
remote: 
To https://gitlab.linuxito.com/emiliano/recoll-webui.git
 * [new branch]      estable -> estable
Branch 'estable' set up to track remote branch 'estable' from 'origin'.

Lo mismo para la rama "desarrollo":

root@debian:/var/www/recoll-webui# git checkout desarrollo
Switched to branch 'desarrollo'

root@debian:/var/www/recoll-webui# git push -u origin desarrollo
Total 0 (delta 0), reused 0 (delta 0)
remote: 
remote: To create a merge request for desarrollo, visit:
remote:   https://gitlab.linuxito.com/emiliano/recoll-webui/merge_requests/new?merge_request%5Bsource_branch%5D=desarrollo
remote: 
To https://gitlab.linuxito.com/emiliano/recoll-webui.git
 * [new branch]      desarrollo -> desarrollo
Branch 'desarrollo' set up to track remote branch 'desarrollo' from 'origin'.

De forma alternativa, y más simple, es posible recurrir al comando git push --all origin para enviar todos los cambios de todas las ramas de una vez.

Clonar una rama específica

Tenemos nuestra copia local en el directorio /var/www/recoll-webui sincronizada contra la rama "estable". Esta copia local corresponde a la aplicación en producción donde se aplicarán cambios estables a largo plazo y debidamente testeados.

A continuación se procede con el clonado de una nueva copia local en el directorio /var/www/recoll-webui-desa, sincronizada contra la rama "desarrollo". Esta copia local corresponde a la aplicación en testing.

Es posible clonar una rama específica de un repositorio pasándola como parámetro a la opción --branch:

root@debian:/var/www/recoll-webui# cd ..
root@debian:/var/www# git clone --branch desarrollo https://gitlab.uns.edu.ar/emiliano/recoll-webui.git recoll-webui-desa
Cloning into 'recoll-webui-desa'...
remote: Enumerating objects: 320, done.
remote: Total 320 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (320/320), 137.10 KiB | 19.58 MiB/s, done.
Resolving deltas: 100% (194/194), done.

Veamos si está sincronizada contra la rama correcta:

root@debian:/var/www# cd recoll-webui-desa/

Notar que esta copia local no posee todas las ramas, sino sólo "desarrollo":

root@debian:/var/www/recoll-webui-desa# git branch
* desarrollo

Mantener las copias locales sincronizadas

De esta forma podemos tener dos copias locales de un repositorio en un servidor apuntando a ramas diferentes: una estable para el sitio en producción y una de desarrollo para el sitio en desarrollo/prueba. Sólo restar configurar Apache/Nginx para que el alias o nombre de host de desarrollo apunte a este nuevo directorio.

Ahora a picar código y pushear a la rama "desarrollo".

Desde el lado servidor sólo se debería correr git pull periódicamente para bajar los cambios introducidos en la rama "desarrollo".

En este ejemplo se está utilizando GitLab como gestor de repositorios. Sin embargo, si se ha creado un repositorio bare sobre un un servidor git montado de forma manual, anteriormente expliqué cómo implementar una estrategia de deploy automático en una copia local.