Trabajo en equipo sin confusión: comprender las estrategias de ramificación en Git

Introducción

Git se ha convertido en el estándar industrial de facto para los sistemas de control de versiones en el desarrollo de software. Primero deberías leer mi artículo sobre qué es Git y cómo empezar. ¿Lo has leído? Excelente, ¡vamos! Nos guste o no, esta herramienta creada por Linus Tovalds no se va a jubilar. Por lo tanto, tiene sentido hablar sobre cómo funcionan los equipos distribuidos con Git y qué estrategia de ramificación deben elegir para esto. Esta no es una pregunta intrascendente. Cuando se forma un nuevo equipo de desarrollo que no ha trabajado en conjunto anteriormente, la estrategia de ramificación suele ser una de las primeras cosas que se deben decidir. Y algunas personas echarán espuma por la boca para demostrar que una estrategia es mejor que otra. Por lo tanto, quiero transmitirles algunos datos generales sobre ellos.

¿Son necesarias las estrategias de ramificación?

De hecho, son necesarios. Muy necesario. Porque si el equipo no está de acuerdo en algo, entonces cada miembro del equipo hará lo que quiera:

• trabajando en cualquier rama
• fusionándose en otras ramas arbitrarias
• eliminando algunas ramas
• creando otros nuevos
• y así cada miembro del equipo actuará en un flujo no gestionado.

Es por eso que tenemos tres estrategias a considerar a continuación. ¡Vamos!

Flujo de GitHub

Esta estrategia de bifurcación, por extraño que parezca, se prefiere en GitHub :) Viene con un conjunto de reglas :

1. El código en la rama maestra no debe romperse. Debe estar listo para ser desplegado en cualquier momento. Es decir, no debe colocar código allí que le impida compilar el proyecto e implementarlo en el servidor.
2. Cuando planee trabajar en una nueva funcionalidad, debe crear una nueva rama de función basada en la rama maestra y darle un nombre significativo. Confirme su código localmente y envíe sus cambios regularmente a la misma rama en el repositorio remoto.
3. Abra una solicitud de extracción (puede leer sobre las solicitudes de extracción aquí ) cuando crea que el trabajo está listo y se puede fusionar en la rama maestra (o si no está seguro, pero desea recibir comentarios sobre el trabajo realizado).
4. Una vez que se aprueba la nueva función en la solicitud de incorporación de cambios, se puede fusionar con la rama principal.
5. Cuando los cambios se combinan en la rama maestra, deben implementarse en el servidor de inmediato.

De acuerdo con GitHub Flow, antes de comenzar a trabajar en algo nuevo, ya sea una solución o una nueva función, debe crear una nueva rama basada en el maestro y darle un nombre adecuado. A continuación, comienza el trabajo de implementación. Debe enviar constantemente confirmaciones al servidor remoto con el mismo nombre. Cuando concluya que todo está listo, debe crear una solicitud de extracción para la rama principal. Entonces, al menos una, o mejor aún, dos personas deberían mirar este código antes de hacer clic en "Aprobar". Por lo general, el líder del equipo del proyecto y una segunda persona definitivamente deberían echar un vistazo. Luego puede completar la solicitud de extracción. GitHub Flow también es conocido por impulsar la entrega continua (CD) en proyectos. Esto se debe a que cuando los cambios ingresan a la rama maestra, deben implementarse en el servidor de inmediato.

GitFlow

La estrategia anterior (GitHub Flow) no es muy complicada en su esencia. Hay dos tipos de ramas: ramas maestras y funciones. Pero GitFlow es más serio. Al menos, la imagen de arriba debería dejar eso claro :) Entonces, ¿cómo funciona esta estrategia? En general, GitFlow consta de dos ramas persistentes y varios tipos de ramas temporales. En el contexto de GitHub Flow, la rama maestra es persistente y las demás son temporales. Ramas persistentes

• maestro: Nadie debe tocar o empujar nada a esta rama. En esta estrategia, master representa la última versión estable, que se utiliza en producción (es decir, en un servidor real)
• desarrollo: La rama de desarrollo. Podría ser inestable.

El desarrollo ocurre usando tres ramas temporales auxiliares :

1. Ramas de características: para desarrollar nuevas funciones.
2. Ramas de lanzamiento: para prepararse para el lanzamiento de una nueva versión del proyecto.
3. Ramas de revisión: para corregir rápidamente un error encontrado por usuarios reales en un servidor real.

Ramas de características

Los desarrolladores crean ramas de características para una nueva funcionalidad. Siempre deben crearse en función de la rama de desarrollo. Después de completar el trabajo en la nueva funcionalidad, debe crear una solicitud de extracción para la rama de desarrollo. Claramente, los equipos grandes pueden tener más de una rama de funciones a la vez. Eche otro vistazo a la imagen al principio de la descripción de la estrategia de GitFlow.

Liberar ramas

Cuando el conjunto requerido de nuevas características esté listo en la rama de desarrollo, puede prepararse para el lanzamiento de una nueva versión del producto. Una rama de lanzamiento, que se crea en base a la rama de desarrollo, nos ayudará con esto. Cuando trabaje con la rama de lanzamiento, debe encontrar y corregir todos los errores. Cualquier cambio nuevo que se requiera para estabilizar la rama de lanzamiento también debe fusionarse nuevamente en la rama de desarrollo. Esto se hace para estabilizar también la rama de desarrollo. Cuando los evaluadores dicen que la rama es lo suficientemente estable para una nueva versión, se fusiona con la rama maestra. Posteriormente, se crea una etiqueta, a la que se le asigna un número de versión, para esta confirmación. Para ver un ejemplo, mire la imagen al comienzo de la estrategia. Ahí verás la Etiqueta 1.0— esta es solo una etiqueta que indica la versión 1.0 del proyecto. Y finalmente, tenemos la rama de revisión.

Ramas de revisión

Las ramas Hotfix también están destinadas a lanzar una nueva versión en la rama maestra. La única diferencia es que esos lanzamientos no están planeados. Hay situaciones en las que los errores ingresan a la versión lanzada y se descubren en el entorno de producción. Tome iOS: tan pronto como se lanza una nueva versión, inmediatamente obtiene un montón de actualizaciones con correcciones para errores que se encontraron después del lanzamiento. En consecuencia, necesitamos corregir rápidamente un error y lanzar una nueva versión. En nuestra imagen, esto corresponde a la versión 1.0.1. La idea es que el trabajo en la nueva funcionalidad no tenga que detenerse cuando sea necesario corregir un error en un servidor real (o como decimos, "en producción" o "en producción"). La rama de revisión debe crearse a partir de la rama maestra, ya que representa lo que se está ejecutando actualmente en producción. Tan pronto como la corrección del error esté lista, se fusiona con el maestro y se crea una nueva etiqueta. Al igual que preparar una rama de lanzamiento, una rama de revisión también debe fusionar su corrección nuevamente en la rama de desarrollo.

Flujo de trabajo de bifurcación

En el flujo de trabajo de bifurcación, el desarrollo involucra dos repositorios:

1. El repositorio original, en el que se fusionarán todos los cambios.
2. Un repositorio de bifurcaciones. Esta es una copia del repositorio original, propiedad de otro desarrollador que desea realizar cambios en el original.

Suena un poco extraño hasta ahora, ¿verdad? Cualquiera que ya se haya encontrado con el desarrollo de código abierto ya está familiarizado con este enfoque. Esta estrategia brinda la siguiente ventaja: el desarrollo puede ocurrir en un repositorio de bifurcación sin otorgar permisos para el desarrollo conjunto en la rama original. Naturalmente, el propietario del repositorio original tiene derecho a rechazar los cambios propuestos. O aceptarlos y fusionarlos. Esto es conveniente tanto para el propietario del repositorio original como para el desarrollador que quiere ayudar a crear el producto. Por ejemplo, puede sugerir cambios en el kernel de Linux . Si Linus decide que tienen sentido, se agregarán los cambios (!!!).

Un ejemplo del flujo de trabajo de bifurcación

El flujo de trabajo de bifurcación se aplica en GitHub cuando hay una biblioteca que desea usar. Tiene un error que le impide usarlo por completo. Suponga que profundiza lo suficiente en el problema y conoce la solución. Con el flujo de trabajo de bifurcación, puede solucionar el problema sin derechos para trabajar en el repositorio original de la biblioteca. Para comenzar, debe seleccionar algún repositorio, por ejemplo, Spring Framework . Busque y haga clic en el botón "Tenedor" en la esquina superior derecha: esto llevará algún tiempo. Luego aparecerá una copia del repositorio original en tu cuenta personal, que te indicará que se trata de un fork:Ahora puede trabajar con este repositorio como de costumbre, agregando cambios a la rama principal y, cuando todo esté listo, puede crear una solicitud de extracción para el repositorio original. Para hacer esto, haga clic en el botón Nueva solicitud de extracción :

Qué estrategia elegir

Git es una herramienta flexible y poderosa que te permite trabajar usando una amplia variedad de procesos y estrategias. Pero cuantas más opciones tenga, más difícil será decidir qué estrategia elegir. Está claro que no hay una respuesta única para todos. Todo depende de la situación. Dicho esto, hay varias pautas que pueden ayudar con esto:

1. Es mejor elegir primero la estrategia más simple. Pasar a estrategias más complejas solo cuando sea necesario.
2. Considere estrategias que tengan la menor cantidad posible de tipos de ramas para los desarrolladores.
3. Mire los pros y los contras de las diversas estrategias y luego elija la que necesita para su proyecto.

Eso es todo lo que quería decir sobre las estrategias de ramificación en Git. Gracias por su atención :) Síganme en GitHub , donde a menudo publico mis creaciones que involucran diferentes tecnologías y herramientas que utilizo en mi trabajo.