Un modelo de ramificacin exitoso en git.

Miguel Pia

[2015-03-22 lun 11:32]

Contents

1 Por qu GIT? 2

2 Descentralizado pero centralizado. 3

3 Las ramas principales 4

4 Soportando ramificaciones 54.1 Ramas de caractersticas . . . . . . . . . . . . . . . . . . . . . 6

4.1.1 Creando una rama de caractersticas . . . . . . . . . . 84.1.2 Incorporando una caracterstica terminado en develop 8

4.2 Ramas de lanzamiento . . . . . . . . . . . . . . . . . . . . . . 94.2.1 Creando una rama de lanzamiento . . . . . . . . . . . 104.2.2 Terminando una rama de lanzamiento . . . . . . . . . 11

4.3 Ramas de correcciones . . . . . . . . . . . . . . . . . . . . . . 124.3.1 Creando una rama de correccin . . . . . . . . . . . . 134.3.2 Terminando una rama de correccin . . . . . . . . . . 14

En este post presento el modelo de desarrollo que he ido introduciendopara todos mis proyectos (de trabajo y privados) desde hace un ao, y elcual se ha mostrado realmente exitoso. He estado queriendo escribir sobrel desde hace un tiempo, pero nunca he encontrado el tiempo para hacerlobien, hasta ahora. No voy a hablar de los detalles en los proyectos, si no dela estrategia de ramificacin y gestin de lanzamientos.

1

Est enfocado alrededor de git como herramienta de versionado de todonuestro cdigo.

1 Por qu GIT?

Para una discusin detallada acerca de los pros y contras de Git en com-paracin con otras herramientas de control de versiones, pueden consultar la

2

web. Hay toda una gran discusin sobre eso. Como desarrollador, prefieroGit sobre todas las otras herramientas que hay hoy en da. Git realmente hacambiado la forma en que los desarrolladores piensan el mezclado y la rami-ficacin de cdigo. Desde el clsico CVS/Subversin del que vengo, siemprese han considerado de miedo ("Cuidado con los conflictos de mezclas, ellospueden morderte!"), algo que pasa de vez en cuando.

Pero con Git, esas acciones son extremadamente baratas y simples, lascuales son consideradas como parte del flujo de trabajo diario. Por ejemplo,en los libros de CVS/Subversin, la ramificacin y el mezclado son discutidosen los captulos finales (para usuarios avanzados), mientras que en cualquierlibro de Git, esto es cubierto en el captulo 3 (cosas bsicas).

Como consecuencia de su simplicidad y naturaleza repetitiva, la ramifi-cacin y el mezclado ya no son cosas de las que hay que temer. Las herramien-tas de versionados se suponen que deben ayudar en la ramificacin/mezcladosobre cualquier otra cosa.

Suficiente sobre las herramientas, vamos hacia el modelo de desarrollo.El modelo que voy a presentar aqu, es esencialmente un conjunto de proced-imientos que todo miembro del equipo tiene que seguir en orden para tenerun proceso de software administrado.

2 Descentralizado pero centralizado.

La configuracin del repositorio que usamos y que trabaja bien con estemodelo de ramificaciones, es ese con un repositorio central "verdadero". Noteque este repositorio es slo considerado como el central (ya que Git es unDVCS, no hay tal cosa como un repositorio central a nivel tcnico). Nosvamos a referir a este repositorio como origin, ya que este nombre es familiarpara todos los usuario de Git.

3

Cada desarrollar pulls y pushes a origin. Pero adems de las relacionespush-pull centralizados, cada desarrollador puede tambin extraer los cam-bios de otro desarrollador. Por ejemplo, esto podra ser til para que trabajendos o ms desarrolladores en una gran novedad antes de empujar el trabajoen curso con origin de manera prematura. En la figura anterior, hay equipossecundarios de Alice y Bob, Alice y David, y Clair y David.

Tcnicamente, esto significa nada ms que Alice ha definido un control,tomado desde el repositorio de bob, y viceversa.

3 Las ramas principales

En el ncleo, el modelo de desarrollo est inspirado por los modelos existentesque hay. El repositorio central mantiene dos ramas principales con vidainfinita:

Master

Develop

La rama master en origin debera ser familiar para todo usuario de Git.Paralelo a master, existe otra rama llamada develop.

4

Nosotros consideramos a origin/master para ser la rama principaldonde el cdigo fuente de HEAD siempre apunta un estado listo-para-produccin.

Nosotros consideramos a origin/develop para ser la rama principaldonde el cdigo fuente de HEAD siempre refleja el estado con los ltimoscambios liberados para la siguiente liberacin. Algunos podran llamarlacomo la rama de "integracin". Aqu es donde cualquier nightly build puedeser construida.

Cuando el cdigo fuente en la rama develop alcanza un punto establey est lista para ser liberada, todos los cambios deberan ser mezclados enmaster y entonces etiquetados con un nmero de versin. Ms adelantevamos a discutir el cmo se realiza esto.

Por lo tanto, cada vez cuando los cambios son mezclados enmaster, estoimplica que esta en produccin por definicin. Podemos ser muy estrictoscon esto, por lo que, en teora podemos tener un script de Git para construirnuestro proyecto de manera automtica y poner en marcha nuestro softwarepara nuestros servidores de produccin cada vez que haya un commit enmaster.

4 Soportando ramificaciones

Adems de las ramas principales master y develop, nuestro modelo de de-sarrollo usa una variedad de ramas de soporte para ayudar el desarrollo enparalelo entre los miembros del equipo, as como un fcil seguimiento decaractersticas, preparacin para las liberaciones en produccin y asistir rp-idamente a resolver problemas con el sistema en produccin. A diferencia delas ramas principales, esas ramas siempre tiene un tiempo de vida limitado,por lo que tendrn que ser eliminadas eventualmente.

Los diferentes tipos de ramas que tal vez usemos son:

Ramas de caractersticas

Ramas de liberacin

Ramas hotfix

Cada una de esas ramas tiene un propsito especfico y estn acotadospor reglas estrictas, por ejemplo, de que ramas pueden ser originadas y cualesson las ramas con las que deben ser mezcladas. Vamos a revisarlas en unminuto.

5

De ninguna forma estas son ramas especiales desde una perspectiva tc-nica. Los tipos de ramas va estar categorizadas por la forma en que vamosa usarlas. Son por supuesto, las viejas y simples ramas de Git.

4.1 Ramas de caractersticas

Pueden ramificar desde:

develop

Deben ser mezcaldas en:

Develop

Convencin de nombres:

Cualquiera, excepto: master, develop, release-* o hotfix-*

Las ramas de caractersticas (o algunas veces llamadas ramas puntuales)son usadas para desarrollar nuevas caractersticas a futuro o para una ver-sin futura distante. Al iniciar el desarrollo de una caracterstica, el releaseobjetivo en la cul esta caracterstica va a ser incluida tal vez puede serdesconocida en ese punto. La esencia de una rama de caracterstica es queexiste siempre y cuando la funcin se encuentra en desarrollo, pero con eltiempo se mezcla en develop (aadida como una caracterstica para la prx-ima liberacin) o deshechada (en caso de ser un experimente descepcionante).

Las ramas de caractersticas normalmente viven en los repositorios de losdesarrollador, no en origin.

6

7

4.1.1 Creando una rama de caractersticas

Cuando iniciamos el trabajo en nueva caracterstica, debemos ramificar desdela rama develop.

$ git checkout -b miCaracteristica develop

4.1.2 Incorporando una caracterstica terminado en develop

Las caractersticas terminadas pueden ser mezcladas en la rama developcuando van a ser aadidas de manera definitiva para la prxima liberacin:

$ git checkout Develop# Intercambio a la rama develop$ git merge --no-ff miCaracteristica# Updating ea1b82a..05e9557#(Summary of changes)$ git branch -d myfeature# Deleted branch myfeature (was 05e9557).$ git push origin develop

El flag no-ff causa que la mezcla siempre cree un nuevo objeto commit,incluso si la mezcla podra ser realizada con un fast-foward. Esto evita laperdida de informacin sobre la existencia histrica de una rama de carac-tersticas y agrupar todas las confirmaciones que agregan la funcin. Com-paremos:

8

En el ltimo caso, es imposible ver desde la historia de Git cuales fueronlos commits que se hicieron para implementar una caracterstica. Podrastener que leer de manera manual todos los logs. Revertir toda una carac-terstica (conjunto de commits), es un dolor de cabeza en la ltima situacin,mientras que es fcilmente hacerlo si hubieras usado el flag no-ff.

S, vas a crear unos cuantos ms commits (vacos), pero la ganancia esmucho ms grande que ese costo.

Por desgracia, no he encontrado una manera de hacer no-ff el com-portamiento predeterminado de git merge, pero realmente es lo que deberaser.

4.2 Ramas de lanzamiento

Pueden ser ramificadas desde:

develop

Deben ser mezcladas en:

develop y master

9

Convencin de nombres:

release-*

Las ramas de lanzamiento soportan la preparacin de una nueva lib-eracin en produccin. Ellas permiten realizar cambios de ltimo minuto.As tambin realizar correcciones y preparar los metadatos para el lanza-miento (nmeros de versin, fechas de construccin, etc). Haciendo todoeste trabajo sobre una rama de lanzamiento, la rama de develop est listapara recibir caractersticas para el siguiente gran lanzamiento.

El principal momento para ramificar una nueba rama de lanzamientodesde develop es cuando el desarrollo refleja un estado deseado para unanueva liberacin. Al menos todas las caractersticas son enviadas para ellanzamiento, construidas al ser mezcladas en develop en este punto. Todaslas caractersticas enviadas a lanzamientos futuros no deben estar incluidas- deben esperar a su momento.

En el momento de iniciar una rama de lanzamiento cuando se le asignaun nmero de versin (no antes). Hasta ese momento, la rama developrefleja los cambios para la "prxima liberacin", no est claro si ese prx-imo lanzamiento se convertir en 0.3 o 1.0, hasta que se inicie la rama delanzamiento.

4.2.1 Creando una rama de lanzamiento

La ramas de lanzamiento son creadas desde la rama develop. Por ejemplo,digamos que la versin 1.1.5 es la versin actual en produccin y nosotrostenemos una gran liberacin pronto. El estado de develop est listo para la"siguiente liberacin" y nosotros tenemos que decidir que va ir en la versin1.2 (en lugar de 1.1.6 o 2.0). As nosotros ramificamos y damos la rama delanzamiento el nombre que refleje el nuevo nmero de versin.

git checkout -b release-1.2 develop# Creamos una nueva rama "release-1.2" y nos movemos a ella./bump-version.sh 1.2# Cambiamos los archivos indicado la versin 1.2git commit -a -m "Cambio de versin a 1.2"# [release-1.2 74d9424] Cambio de versin a 1.2# 1 files changed, 1 insertions(+), 1 deletions(-)

Despus de crear la nueva rama y movernos a ella, cambiamos el nmerode versin. Aqu bump-version.sh es un script imaginario que cambia al-gunos archivos en la copia de trabajo para reflejar la nueva versin (Esto

10

puede ser por supuesto un cambio manual, el punto es cambiar algunosarchivos). Entonces, el nmero de versin es commiteado.

Esta nueva rama puede existir por un tiempo, hasta que la liberacinsea terminada definitivamente. Durante ese tiempo, se reparan los erroresque puedan existir en esa rama (en lugar de la rama de desarrollo). Aadirnuevas caractersticas grandes est estrictamente prohibido. Estas deben sermezcladas en develop y esperar para el siguiente lanzamiento.

4.2.2 Terminando una rama de lanzamiento

Cuando el estado de una rama de lanzamiento est lista para ser un lan-zamiento rela, algunas acciones deben ser realizadas. Primero, la rama delanzamiento es mezclada en master (Debido a que cada commit en masteres un nuevo lanzamiento por definicin, recuerdas?). Despus, ese commit enmaster debe ser etiquetado para tener una referencia futura. Finalmente,los cambios realizados en la rama de liberacin deben ser mezclados de nuevoen develop.

Los primeros dos pasos en GIT:

git checkout master# Switched to branch mastergit merge --no-ff release-1.2# Merge made by recursive.# (Summary of changes)$ git tag -a 1.2

El lanzamiento est hecho, y etiquetado para futuras referencias.Para mantener esos cambios realizados en la rama de liberacin, debemos

de mezclarlos de vuelta en develop. En GIT:

git checkout develop# Switched to branch developgit merge --no-ff release-1.2# Merge made by recursive.# (Summary of changes)

Este paso podra tener algunos conflictos al mezclar (probablemente al-gunos, desde que cambios el nmero de versin). Si es as, los corregimos yhacemos commit.

Ahora debemos eliminar la rama de lanzamiento debido a que ya no lavamos a seguir usando.

11

git branch -d release-1.2# Deleted branch release-1.2 (was ff452fe).

4.3 Ramas de correcciones

Pueden ser ramificadas desde:

Master

Deben ser mezcladas en:

develop y master

Convencin de nombrado:

hotfix-*

Las ramas de correcin son muy parecidas a las ramas de lanzamientoen que ellas tambin se preparan para un nuevo lanzamiento en produccin,aunque no sea planeado. Estas ramas nacen de la necesidad de cambiar unestado no deseado de una versin en produccin. Cuando hay un error crticoen produccin, esto debe ser resuelto inmediatamente, entonces se ramificauna rama de correccin a partir de la correspondiente etiqueta que marca laversin en produccin.

Esencialmente el trabajo del equipo (sobre develop) puede continuar,mientras otra persona puede preparar una correccin rpida en produccin.

12

4.3.1 Creando una rama de correccin

Las ramas de correccin son creadas a partir de la rama master. Porejemplo, digamos que la versin 1.2 es la versin en produccin actual y estcausando problemas debido a un error. Pero los cambios en develop anson inestables. Nosotros podemos ramificar una rama de correccin e iniciara resolver el problema.

13

$ git checkout -b hotfix-1.2.1 master# Switched to a new branch "hotfix-1.2.1"$ ./bump-version.sh 1.2.1# Files modified successfully, version bumped to 1.2.1.$ git commit -a -m "Bumped version number to 1.2.1"# [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1# 1 files changed, 1 insertions(+), 1 deletions(-)

No olvides realizar el cambio de versin despus de ramificar!Entonces, corregimos el error y comiteamos el error en uno o ms commits

separados.

git commit -m "Fixed severe production problem"# [hotfix-1.2.1 abbe5d6] Fixed severe production problem# 5 files changed, 32 insertions(+), 17 deletions(-)

4.3.2 Terminando una rama de correccin

Cuando terminemos, la correccin del error necesita ser mezclada de nuevo enmaster, pero tambin necesitamos mezclarla de vuelta en develop, de formaque podamos asegurar que la correccin sea incluida en la siguiente versintambin. Esto es completamente similar a como las ramas de lanzamientoson terminadas.

Primero, actualizamos master y la etiqueta de la liberacin:

git checkout master# Switched to branch mastergit merge --no-ff hotfix-1.2.1# Merge made by recursive.# (Summary of changes)git tag -a 1.2.1

Lo siguiente es incluir la correccin en develop:

git checkout develop# Switched to branch developgit merge --no-ff hotfix-1.2.1# Merge made by recursive.# (Summary of changes)

14

La nica excepcin a la regla es que, cuando una rama de lanza-miento exista, la correccin necesita ser mezclada en al rama deliberacin en lugar de la de develop. Mezclando la correccin en la ramade lanzamiento, eventualmente va a ser mezclada en develop tambin. (Siel trabajo en develop requiere mezclar esta correccin y no pueden esperarhasta que la rama de lanzamiento termine, puedes mezclar la correccinseguramente en develop tambin).

Finalmente, eliminamos la rama de correccin:

git branch -d hotfix-1.2.1# Deleted branch hotfix-1.2.1 (was abbe5d6).

Comentario: Este documento es una traduccin de "A succesful Gitbranching model".

15

Por qu GIT?Descentralizado pero centralizado.Las ramas principalesSoportando ramificacionesRamas de caractersticasCreando una rama de caractersticasIncorporando una caracterstica terminado en develop

Ramas de lanzamientoCreando una rama de lanzamientoTerminando una rama de lanzamiento

Ramas de correccionesCreando una rama de correccinTerminando una rama de correccin