Un modelo exitoso de ramas en Git

Para utilizar el Git es importante, y eso incluye mantener un entorno de desarrollo colaborativo de software manejable.

Créditos

Este Post es una versión en portugués del original, en inglés, “Un modelo exitoso de ramificación de Git“, debidamente autorizados por el autor, Vincent Driessen. Gracias hombre!

Para cuestiones técnicas, Algunas palabras claves han sido deliberadamente mantenidos en inglés. He intentado garantizar la originalidad del texto, pero confieso que tuve que hacer ajustes para facilitar la comprensión de nuestro idioma (EN). Es bienvenida cualquier corrección o sugerencia para la mejora en la traducción.

Introducción

Este no es un Post que enseña a usar Git. Si esto es lo que necesita, Te sugiero echar un vistazo a Manual de Git. Tampoco es nuestro objetivo mostrar como se hace un control de versiones de software, en este caso, Ver Versiones de semántica.

La propuesta es lograr la colaboración del equipo de control de versiones de software. Sabes cuando tienes varios programadores “revolviendo” en el mismo código fuente? Es importante para acelerar el desarrollo, pero puede generar dolor de cabeza enorme (prejuicios y reanudación) Si hay un control. Para evitar que un desarrollador sobreescribir cada uno de trabajar y garantizar un desarrollo progresivo y organizado, minimización de conflictos y gestión de versiones de software, es que usamos Git y el modelo de sucursales entonces.

Plantilla en blanco

En este post les presento el modelo de desarrollo que he usado en algunos de mis proyectos (trabajar como particular) Acerca de 1 hace años, y que ha sido muy exitoso. Ha sido mucho tiempo que quería escribir sobre él, pero nunca encontró un horario disponible, hasta el momento. No voy a discutir los detalles del proyecto, sólo acerca de las estrategias de sucursales y gestión de comunicados de.

Este modelo se centra exclusivamente en Git como una herramienta para el control de versiones de todo nuestro código fuente. (A propósito, Si usted está interesado en Git, nuestra empresa GitPrime proporciona, en tiempo real, algunos increíble análisis de datos para la optimización de la ingeniería de software)

Por qué git?

Para una discusión cuidadosa de los pros y los contras de Git frente a sistemas de control de código fuente centralizada, Ver el Web. Hay una tremenda “guerra” alrededor de eso. Como un desarrollador, Prefiero Git en relación con todas las demás herramientas existentes hoy. Git sin duda cambió la forma en que los desarrolladores pensar en hacer un Fusión o crear un rama. Vengo del mundo clásico de la CVS/Subversion, donde fusión/sucursales Es algo que sólo de vez en cuando y siempre se ve un poco de miedo (“Cuidado con los conflictos de Fusión, te muerden!”).

Con Git estas acciones [fusión/sucursales] son extremadamente simple y representan una parte importante de nuestra rutina de trabajo, Créeme. Por ejemplo, en Libro CSV/Subversion, ramificación y fusión están cubiertos por primera vez en últimos capítulos (para usuarios avanzados), Mientras que en cualquier libro sobre Git, Esto se ve en el capítulo 3 (conceptos básicos).

Como resultado de su simplicidad y naturaleza repetitiva, ramificación y fusión ya no son algo que temer. Realmente, herramientas de control de versión deben hacerFusión y crear rama más que nada.

No más hablar, Vamos a ir para el modelo de desarrollo. El modelo que voy a presentar aquí es esencialmente nada más que un conjunto de procesos que cada miembro del equipo debe seguir para llegar a un proceso de desarrollo de software administrado.

Descentralizados, pero centrado en

La configuración de los repositorios que uso y que funciona muy bien con este modelo ramificación se compone de un repositorio central. Tenga en cuenta que este depósito es sólo “considerado como” Central (porque Git es un DVCS [Sistemas de Control de versión distribuido], IE, No hay nada como un repositorio central a nivel técnico). Hará referencia este repositorio como origen, Puesto que este nombre es familiar a todos los usuarios de Git.

Cada desarrollador hace tira y viajes para la origen. Pero más allá de la relación push-pull para centralizado [origen], cada desarrollador puede recoger también [Pull] los cambios de otras parejas para conformar los equipos. Por ejemplo, Esto puede ser útil para trabajar con los desarrolladores de dos o más en una nueva gran funcionalidad, enviar previamente [empujando] trabajo en progreso para la origen. En la figura anterior, Hay los subequipos de Alice y Bob, Alicia y David, y Clair y David.

Técnicamente, Esto significa nada más que Alicia ha definido un Git remoto llamado Bob, hacia el repositorio de Bob, y viceversa.

Las ramas principales

En el fondo, Este modelo de desarrollo está muy inspirada en modelos existentes alrededor. El repositorio central tiene dos ramas [sucursales] principales con una vida infinita:

  • Master
  • desarrollar

El Maestro de la rama en origen deben ser familiares a todos los usuarios de Git. Paralelo a Maestro de la rama, Hay otro rama llama desarrollar.

Tenemos en cuenta origen/master como la rama principal donde el código fuente de CABEZA siempre refleja un estado listo para la producción [listo para la producción].

Tenemos en cuenta origen y desarrollar como ser la rama principal donde el código fuente de CABEZA siempre refleja un estado con los cambios más recientes que se entregará en la próxima versión. Algunos llaman “rama de la integración”. Es donde más siniestros suceden construcciones.

Cuando la fuente de código en el Desarrollo de la rama alcance un estable punto y está listo para ser lanzado [liberado], todos los cambios deberían fusionarse [combinado] volver a la Maestro de la rama y luego marcadas con un número de versión [lanzamiento]. Cómo se hace en detalle, se discutirá más adelante.

Por lo tanto, cada cambio de tiempo se incorpora [combinado] volver a la Master, Ha generado una nueva versión [liberado], por definición. Queremos ser muy rigurosos sobre ello, por lo que, teóricamente, Incluso podríamos utilizar un script gancho Git para crear y enviar automáticamente nuestra aplicación a servidores de producción cada vez que hay un se comprometen en Master.

Ramas auxiliares

Junto a la sucursales principal, Master y desarrollar, nuestro modelo de desarrollo utiliza una variedad de sucursales para ayudar a apoyar el desarrollo simultáneo entre los miembros del equipo, Qué 1) facilita el seguimiento de novedades [características], 2) prepararse para el parto de una nueva versión [lanzamiento] y 3) ayuda a fijar rápidamente defectos en la producción [Hotfix]. A diferencia de sucursales principal, Estos sucursales tiene una vida corta, ahora finalmente se quitará.

Los diferentes tipos de sucursales [ayudantes de] Podemos utilizar, son:

  • Ramas de la función
  • Ramas de liberación
  • Ramas de Hotfix

Cada uno de estos sucursales tiene un propósito específico y está relacionado con reglas estrictas, Para, sucursales puede dar lugar a rama y sucursales debe ser combinado [combinado] los objetivos de sus. Vamos a ver cada uno [sucursales] en un instante.

Bajo una perspectiva técnica, Estos sucursales no se consideran “Especial”. Cada tipo de rama Se categoriza por cómo usamos los. De todos modos, son simples sucursales el buen viejo Git.

Ramas de la función

[Características = características y funcionalidades]

– Rama puede [rama] De:
desarrollar
– Debe combinar-si [Fusión] otra vez la:
desarrollar
– La Convención de nomenclatura rama:
Cualquier cosa, excepto Master, desarrollar, comunicado-*, o Hotfix-*

El ramas de la función (o a veces llamada ramas del tema) son utilizados para desarrollar nuevas características/funcionalidad en una versión próxima o futura. Para iniciar el desarrollo de un característica, la versión de destino en la que se incrustará esta característica puede ser desconocida en este momento.

La esencia de un ramas de la función Es mientras que la característica está en desarrollo, pero eventualmente se incrustará [combinado] volver a la desarrollar (para agregar el nuevo característica a la siguiente lanzamiento) o lanzado (en el caso de una experiencia fracasada).

Ramas de la función por lo general sólo existe en el repositorio desarrollar, no en origen.

Crear una función con ramas

$ git checkout -b myfeature desarrollar
# Switched to a new branch "myfeature"

Incorporando una función terminó en el desarrollo

Características finalizado puede combinar[combinado] con el Desarrollo de la rama Añadir a siguiente lanzamiento.

$ desarrollo de Git checkout
# Cambiado a rama 'desarrollar'
$ combinación de Git --en-FF myfeature
# Actualizando ea1b82a... 05e9557
# (Resumen de los cambios)
# $ git branch-d myfeature
# Myfeature rama eliminados (fue 05e9557).
$ desarrollo de origen del empuje de Git

La bandera –No-ff provoca la fusión [Fusión] siempre crea un nuevo objeto de se comprometen, Aunque la fusión podría realizarse con un avance rápido [FF]. Esto evita pérdida de información sobre la historia de la existencia de un rama de característica, agrupar a todos los se compromete que se han agregado a la característica. Comparar:

En este último caso [en la figura anterior], Es imposible ver en la historia de Git que de se compromete fueron puestos en ejecución dentro de un característica; tendrías que leer manualmente todos los mensajes de registro. Revertir una característica una sola pieza (IE, un grupo de se compromete), Es un dolor de cabeza en la última situación, Mientras que es fácil de hacer si la bandera –No-ff se ha utilizado.

Sí, Esto va a crear algunos objetos de más de se compromete (vacío), pero la ganancia es mucho mayor que el costo.

Ramas de liberación

[Liberar = versión de entrega]

– Rama puede [rama] De:
desarrollar
– Debe combinar-si [Fusión] otra vez la:
desarrollar y Master
– La Convención de nomenclatura rama:
comunicado-*

El Ramas de versiones asistir en la preparación de una nueva versión de la producción [lanzamiento de la producción]. Ellos le permiten poner los puntos sobre de última hora. Además, Permiten pequeñas correcciones de errores errores y la definición de meta datos para un lanzamiento (número de versión, construir las fechas, etcetera). Para hacer todo este trabajo un rama, el desarrollar la rama alojarte limpio para recibir características la siguiente gran lanzamiento [Versión].

El momento clave para crear una nueva rama ramificación de desarrollar es cuando el desarrollar ya está (casi) que reflejan el estado deseado de nuevo lanzamiento [Versión]. Todos características candidatos para la lanzamiento para construir debe ser incorporados [Fusión] el desarrollar en este momento. Ya la características frente a comunicados de futuro debe esperar un siguiente lanzamiento [Versión].

Es exactamente en el comienzo de una rama que la siguiente lanzamiento Obtiene un número de versión – no antes de. Hasta ese momento, el desarrollar la rama refleja cambios en la “próximo lanzamiento” [próxima versión], pero no está claro si esta “próxima versión” eventualmente será 0.3 o 1.0, hasta que el rama se inicia. Esta decisión se toma al principio de la rama y se realiza por las normas del proyecto de control de versiones [Sugiero consulte Acerca de “Versiones de semántica“].

Creación de una rama

El Ramas de versiones creado a partir de la desarrollar la rama. Por ejemplo, Digamos que la versión 1.1.5 es la versión de producción actual y tenemos una gran lanzamiento que viene. El estado de desarrollar Estás listo para el “próxima versión” [próximo lanzamiento] y decidimos que esto se convertiría en la versión 1.2 (En lugar de 1.1.6 o 2.0). Por lo tanto, Ha ampliado y dar rama un nombre que refleja el nuevo número de versión:

$ git checkout -(b) liberación-1.2 desarrollar
# Switched to a new branch "release-1.2"
$ ./Bump-Versión.SH 1.2
# Archivos modificados con éxito, versión al 1.2.
$ git commit -el -m "Bumped version number to 1.2"
# [1.2 lanzamiento 74d 9424] Número de la versión beta a 1.2
# 1 archivos cambiados, 1 inserciones(+), 1 eliminaciones(-)

Después de crear un nuevo rama y acceder a él, En el número de versión. Aquí, Bump-version.sh es un script que cambia algunos archivos de la copia de trabajo para reflejar la nueva versión. (Esto puede, Claro, un cambio manual – el punto es que algunos archivos cambian.) Por lo tanto, se hace la se comprometen el número de versión modificada.

Esta nueva rama Puede haber allí por un tiempo, hasta que el lanzamiento ser lanzado definitivamente. Durante este período, corrección de errores puede ser aplicado en este rama (en vez de la desarrollar la rama). La adición de nuevos y grandes características Aquí está prohibido. Debe ser combinados [combinado] en desarrollar y, Así, esperar para el próximo gran lanzamiento.

Finalización de una rama

Cuando el rama Estás listo para convertirse en una versión real, algunas acciones que deba llevarse a cabo. Primero, el rama se combina en Master (Desde cada uno se comprometen en Master es una nueva versión por definición, Recuerde). Entonces, Esto se comprometen en Master se debe marcar para una fácil referencia futura esta historia de versión. Finalmente, los cambios realizados en el rama necesidad de combinar [combinado] otra vez a desarrollar, para que el comunicados de futuro también contienen estas correcciones.

Los dos primeros pasos en Git:

$ Maestro de Git checkout
# Cambiado a rama 'master'
$ combinación de Git --en-Liberación de SS-1.2
# Combinación de recursivo.
# (Resumen de los cambios)
$ etiqueta de Git -el 1.2

El lanzamiento está ahora completa y marcada para futura referencia.

Nota: También puede utilizar banderas-s o-u firmar la etiqueta cryptographically.

Para guardar los cambios realizados en el rama, Tenemos que ponerlos a la desarrollar. En Git:

$ desarrollo de Git checkout
# Cambiado a rama 'desarrollar'
$ combinación de Git --en-Liberación de SS-1.2
# Combinación de recursivo.
# (Resumen de los cambios)

Este paso puede conducir a un conflicto de combinación (probablemente, Una vez que hemos cambiado el número de versión). Si es así, fijar y hacer la se comprometen.

Ahora, realmente se rompió para arriba, el rama se puede quitar, Ya que no necesitamos ya:

$ rama de Git -lanzamiento d-1.2
# Lanzamiento rama eliminados-1.2 (fue ff452fe).

Ramas de Hotfix

– Rama puede [rama] De:
Master
– Debe combinar-si [Fusión] otra vez la:
desarrollar y Master
– La Convención de nomenclatura rama:
Hotfix-*

El Ramas de Hotfix son muy similares a los Ramas de liberación, También pretende preparar una nueva versión de la producción, Aunque no se planea. Surgen de la necesidad de actuar inmediatamente después de un estado no deseado de una versión de producción [en uso]. Cuando un error crítico en una versión de producción, deben ser resueltos inmediatamente, a continuación, un rama de Hotfix se pueden derivar de la etiqueta que marca la versión de producción existente en Rama Master.

La esencia es que el trabajo de los miembros del equipo (en desarrollar la rama) puede continuar, mientras que otra persona está preparando una rápida corrección de la falla en la producción.

Creación de la rama de hotfix

El ramas de Hotfix creado a partir de la Rama Master. Por ejemplo, Suponiendo que la versión 1.2 es la actual versión de producción corriente y presenta problemas debido a un error grave. Cambios en la desarrollar deja la aún inestable. Nosotros podemos entonces rama una rama de Hotfix y comenzar a solucionar el problema:

$ git checkout -(b) revisión-1.2.1 Master
# Switched to a new branch "hotfix-1.2.1"
$ ./Bump-Versión.SH 1.2.1
# Archivos modificados con éxito, versión al 1.2.1.
$ git commit -el -m "Bumped version number to 1.2.1"
# [Hotfix-1.2.1 41e61bb] Número de la versión beta a 1.2.1
# 1 archivos cambiados, 1 inserciones(+), 1 eliminaciones(-)

No te olvides de cambiar el número de versión después de la ramificación!

Entonces, corregir el error y hacer el se comprometen la corrección en una o más se comprometen separados.

$ git commit -m "Fixed severe production problem"
# [Hotfix-1.2.1 abbe5d6] Problema de la producción severa fija
# 5 archivos cambiados, 32 inserciones(+), 17 eliminaciones(-)

Acabado de una rama de hotfix

Cuando haya terminado, el corrección de errores debe ser combinado a la Master, pero también necesita ser incorporados nuevamente a desarrollar, para asegurarse de que el corrección de errores incluirse también en la próxima versión. Esto es bastante similar al funcionamiento de los Ramas de liberación están finalizados.

Primero, actualización de la Master y la etiqueta del lanzamiento [Seleccione el verano]:

$ Maestro de Git checkout
# Cambiado a rama 'master'
$ combinación de Git --en-Revisión de FF-1.2.1
# Combinación de recursivo.
# (Resumen de los cambios)
$ etiqueta de Git -el 1.2.1

Nota: También puede utilizar banderas-s o-u firmar la etiqueta cryptographically.

Entonces, incluyen la corrección de errores en desarrollar también:

$ desarrollo de Git checkout
# Cambiado a rama 'desarrollar'
$ combinación de Git --en-Revisión de FF-1.2.1
# Combinación de recursivo.
# (Resumen de los cambios)

La única excepción a la regla aquí es, Cuando hay un rama en progreso, los cambios de Hotfix necesidad de ser combinado a este rama, En lugar de desarrollar. Combinar la corrección de errores en rama hará que el corrección de errores se combina en el desarrollar también, Cuando el rama completa. (Si el trabajo en desarrollar requiere inmediatamente corrección de errores y no puede esperar hasta la rama se ha completado, Usted puede combinar de forma segura la corrección de errores para deveolp demasiado.)

Finalmente, Retire el rama temporal:

$ rama de Git -d revisión-1.2.1
# Rama eliminados hotfix-1.2.1 (fue abbe5d6).

Resumen

Aunque no hay nada realmente extraordinario en este modelo de ramificación, la figura al principio del Post puede ser muy útil en nuestros proyectos. Ella muestra un modelo mental fácil de entender y permite que los miembros del equipo a desarrollar un entendimiento común de los procesos de ramificación y liberación de.

Una alta calidad versión PDF de la figura se encuentra en blog del post original: http://nvie.com/posts/a-successful-git-branching-model/ [o el link de descarga abajo]. Seguir adelante y poner en la pared para una referencia rápida a cualquier hora.

Icono

Git-ramificación-modelo-20170825.pdf
3.89 MB 127 descargas

Autor: Vincent Driessen
Blog original: http://nvie.com/
Licencia de: CC BY-SA

Total hits: 2465

Contesta

Su dirección de correo electrónico no será publicado. Campos requeridos están marcados con *