Git se ha convertido en el estándar industrial de facto para el control de versiones en la creación de software. Para saber qué es git y cómo empezar, primero lea mi artículo al respecto. ¿Lo has leído? Genial, ¡sigamos adelante! Nos guste o no, el instrumento que creó Linus Towalds no se va a retirar. Por lo tanto, tiene sentido hablar sobre cómo funcionan los equipos distribuidos en git y qué estrategia de ramificación elegir para ello. Y ésta no es en absoluto una pregunta ociosa. A menudo, en una situación en la que se forma un nuevo equipo de desarrolladores que no han colaborado entre sí, la estrategia de ramificación es una de las primeras cosas que hay que decidir. Y habrá gente que echará espuma por la boca para demostrar que una estrategia es mejor que otra. Por eso, quiero transmitiros información sobre cuáles son generalmente.
¿Son necesarias estrategias de ramificación?
Pero son necesarios y todavía son necesarios. Porque si no os ponéis de acuerdo en algo en el equipo, resulta que cada uno hará lo que quiera:
trabajar en la rama en la que quiera;
fusionarse con otras ramas que quiera;
eliminar algunas ramas;
crear otros nuevos;
y así sucesivamente: cada uno de los miembros del equipo se encuentra en un flujo incontrolado.
Por lo tanto, a continuación se presentan tres estrategias. ¡Ir!
Estrategia de flujo de GitHub
La estrategia de ramificación, por extraña que pueda ser, es la preferida en GitHub :) Se adjunta un conjunto de reglas que deben seguirse:
El código en la rama maestra debe estar intacto y listo para implementarse en cualquier momento (es decir, no puede colocar código allí que le impida crear el proyecto e implementarlo en el servidor).
Cuando planea trabajar en una nueva funcionalidad, necesita crear una nueva rama (rama de características) basada en la rama maestra y darle un nombre significativo. Confirme su código localmente y envíe periódicamente sus cambios a la misma rama en un repositorio remoto.
Abra una solicitud de extracción (puede leer qué es una solicitud de extracción aquí ) cuando tenga una sensación clara de 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 hecho).
Una vez aprobada una nueva característica en una solicitud de extracción, se puede fusionar en la rama maestra.
Cuando los cambios se fusionan en la rama maestra, deben implementarse en el servidor de inmediato.
Según GitHub Flow, resulta que antes de empezar a trabajar en algo nuevo, ya sea una solución o una nueva característica, es necesario crear una nueva rama basada en master y darle un nombre adecuado. A continuación, comienza el trabajo de implementación. Debe enviar constantemente confirmaciones a un servidor remoto con el mismo nombre. Cuando comprenda que todo está listo, deberá crear una solicitud de extracción en la rama maestra. Entonces al menos una, o mejor aún, dos personas deberían mirar este código y hacer clic en Aprobar. Por lo general, el líder del equipo del proyecto y otra persona deben revisarlo y luego usted puede completar la solicitud de extracción. GitHub Flow también es conocido por impulsar la entrega continua (CD) en un proyecto. Porque cuando se realizan cambios en la rama maestra, deben implementarse inmediatamente en el servidor.
estrategia GitFlow
La estrategia anterior (GitHub Flow) no era esencialmente muy compleja. Hay dos tipos de ramas: ramas maestras y de funciones. Pero GitFlow es más serio. Al menos por la imagen de arriba puedes entender esto) Entonces, ¿cómo funciona esta estrategia? En general, GitFlow consta de dos ramas permanentes y varios tipos de ramas temporales (en el contexto de GitHub Flow, la rama maestra es permanente y las demás son temporales). Sucursales permanentes:
Maestro: nadie debe tocar esta rama ni empujar nada allí. En esta estrategia, master muestra la última versión estable que se utiliza en producción (es decir, en el servidor real);
el desarrollo es la rama del desarrollo. Podría ser potencialmente inestable.
El desarrollo se realiza mediante tres ramas temporales auxiliares :
Ramas de funciones: para desarrollar nuevas funciones.
Ramas de lanzamiento: para prepararse para el lanzamiento de una nueva versión del proyecto.
Las ramas de revisión son una solución rápida a un defecto que ya encontraron usuarios reales en un servidor real.
Ramas de características
Los desarrolladores crean ramas de funciones para nuevas funciones. 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 en la rama de desarrollo. Está claro que en equipos grandes puede haber más de una rama de funciones a la vez. Una vez más, preste atención a la imagen al comienzo de la descripción de la estrategia GitFlow.
Liberar ramas
Cuando se haya preparado la cantidad necesaria de nuevas funciones en la rama de desarrollo, podrá prepararse para lanzar una nueva versión del producto. La rama de lanzamiento nos ayudará con esto. que se crea en base a la rama de desarrollo. Mientras trabaja con la rama de lanzamiento, debe encontrar y corregir todos los defectos. Cualquier cambio nuevo que sea necesario para estabilizar la rama de lanzamiento también debe fusionarse nuevamente con el desarrollo. Esto se hace para estabilizar y desarrollar la rama. Cuando los evaluadores dicen que la rama es lo suficientemente estable para una nueva versión, se fusiona con la rama maestra. A continuación, se crea una etiqueta en esta confirmación (etiqueta: puede leer más sobre ella aquí ), a la que se le asigna un número de versión. Como ejemplo, puedes mirar la imagen al comienzo de la estrategia. Entonces, la Etiqueta 1.0 es solo una etiqueta que indica la versión 1.0 del proyecto. Y lo último es una revisión de rama.
Ramas de revisión
Las ramas de revisión también están destinadas al lanzamiento de una nueva versión en master. La única diferencia es que este lanzamiento no está previsto. Hay situaciones en las que los defectos llegan a la liberación y ya se descubren en producción. Por ejemplo, iOS: tan pronto como lanzan una nueva versión, inmediatamente recibes un montón de actualizaciones con correcciones para los defectos que se descubren después del lanzamiento. En este sentido, es necesario solucionar rápidamente este defecto 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 nuevas funciones no se detenga en los momentos en que sea necesario corregir un defecto en un servidor real (como decimos, "en producción": nuevamente, una copia de la palabra inglesa producción). La rama hotfix debe crearse a partir de la rama master, ya que representa el estado que funciona en producción. Tan pronto como la solución al defecto esté lista, se fusiona con master y se crea una nueva etiqueta. Al igual que preparar una rama de lanzamiento, una rama de revisión debe fusionar su solución en la rama de desarrollo.
La estrategia del flujo de trabajo de bifurcación
Como parte de la estrategia Forking Workflow, el desarrollo se realiza de tal forma que existen dos repositorios:
El repositorio original en el que se fusionarán todos los cambios.
Un repositorio fork (es una copia del repositorio original en posesión de otro desarrollador que desea realizar cambios en el original).
Suena un poco extraño hasta ahora, ¿verdad? Para aquellos que ya se han encontrado con el desarrollo de código abierto, este enfoque ya les resulta familiar. Esta estrategia proporciona la siguiente ventaja: el desarrollo se puede llevar a cabo en un repositorio fork sin otorgar derechos de desarrollo conjunto en el original. Por supuesto, el propietario del repositorio original tiene derecho a rechazar los cambios propuestos. O aceptar y matarlos. Esto es conveniente tanto para el propietario del repositorio original como para el desarrollador que quiera participar en la creación de algún producto. Por ejemplo, puedes proponer cambios en el kernel de Linux . Si Linus decide que tienen sentido, se agregarán los cambios (!!!).
El ejemplo del flujo de trabajo de bifurcación
El Forking Flow se usa en GitHub cuando hay alguna biblioteca que desea usar. Tiene un defecto que impide su pleno uso. Digamos que has profundizado lo suficiente en el problema y conoces la solución. Con la estrategia The Forking Workflow, puede resolver este problema sin otorgar derechos para trabajar en el repositorio de la biblioteca original. Para comenzar, debe seleccionar un repositorio, por ejemplo, el núcleo de Spring Framework ... Busque el botón Fork en la esquina superior derecha y haga clic en él: Esto llevará algún tiempo, después del cual aparecerá una copia de este repositorio original en su cuenta personal, lo que indicará que es una bifurcación: Luego puede trabajar con este repositorio como de costumbre, agregar cambios a la rama maestra y cuando todo esté listo, crear una solicitud de extracción al 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 utilizando una amplia gama de procesos y estrategias. Pero cuanto mayor sea la elección, más difícil será decidir qué estrategia elegir ahora. Es evidente que no existe una respuesta única para todos. Todo depende de la situación. Sin embargo, existen algunas recomendaciones que pueden ayudar con esto:
Es mejor elegir primero la estrategia más sencilla. Pase a estrategias más complejas sólo cuando sea necesario.
Considere estrategias que tengan la menor cantidad posible de tipos de ramas de desarrollador.
Mira los pros y los contras de las diferentes estrategias y, de acuerdo con el proyecto, elige la adecuada.
Eso es todo lo que quería contarles sobre la estrategia de ramificación en git. Gracias por su atención :) Suscríbase a mi cuenta de GitHub . A menudo publico allí mi trabajo en diversas tecnologías y herramientas que uso en mi trabajo.
La estrategia de ramificación, por extraña que pueda ser, es la preferida en GitHub :) Se adjunta un conjunto de reglas que deben seguirse:
La estrategia anterior (GitHub Flow) no era esencialmente muy compleja. Hay dos tipos de ramas: ramas maestras y de funciones. Pero GitFlow es más serio. Al menos por la imagen de arriba puedes entender esto) Entonces, ¿cómo funciona esta estrategia? En general, GitFlow consta de dos ramas permanentes y varios tipos de ramas temporales (en el contexto de GitHub Flow, la rama maestra es permanente y las demás son temporales). Sucursales permanentes:
Como parte de la estrategia Forking Workflow, el desarrollo se realiza de tal forma que existen dos repositorios:
Esto llevará algún tiempo, después del cual aparecerá una copia de este repositorio original en su cuenta personal, lo que indicará que es una bifurcación: 
Luego puede trabajar con este repositorio como de costumbre, agregar cambios a la rama maestra y cuando todo esté listo, crear una solicitud de extracción al repositorio original. Para hacer esto, haga clic en el botón Nueva solicitud de extracción : 
GO TO FULL VERSION