Descripción del flujo de trabajo para el uso de git para el desarrollo interno

Question

La empresa para la que trabajo quiere tener lanzamientos mensuales, y estoy tratando de convencerlos de cambiar a git. Creo que la forma correcta de manejar esto es tener una rama de integración para cada versión (es decir, mensualmente) y tener ramas de funciones fuera de las ramas de integración para nuevos desarrollos y cambios. El entorno está cargado de interdependencias y, a veces, una función debe posponerse en un mes diferente debido a retrasos en las funciones requeridas de otros sistemas externos. Los proyectos generalmente tendrán actividad en 2 a 3 ramas de integración en paralelo y la actividad se limita a un grupo de personas que están en contacto bastante cercano. (Lo que significa que sospecho que podemos usar el rebasing siempre que estemos en la última rama de integración, lo cual es cierto al menos la mitad de las veces para la mitad de las personas)

Hay mucha gente involucrada, entonces realmente necesito algunas pautas directas de cómo hacer esto, una explicación lógica de la estructura de bifurcación/combinación y los comandos git prácticos para hacer esto. ¿Alguien sabe de una descripción que se ajuste razonablemente a dicho flujo de trabajo?

Answer 1

una explicación lógica de la estructura de ramas/fusión

La estructura sigue básicamente lo que ha dicho: una rama de la integración, y cuenta con sucursales.
En este tipo de flujo de trabajo, es clave para entender, como lo hizo, que todo el desarrollo no llegará a la próxima versión.
Pero con un DVCS, también es clave para entender que una rama se puede publicar y clonar.

Este último punto (publicación) tendrá una gran influencia en la combinación de los comandos , a saber:

• fusión
• rebase.

Cada vez que un desarrollador tiene que combinar su trabajo en cualquiera de las ramas de integración (que sacó de un repositorio "central"), yo recomendaría:

# switch back to previous release tag (from where feature branches for next release where done) 
$ git checkout previousReleaseTag 
# create one's own private 
$ git checkout -b myIntegrationBranch 
# merge or cherry-pick what we want to actually put in the next release 
$ git merge... from our feature branch 
# rebase that private integration branch on top of actual integration branch 
$ git rebase integrationBranch 

La última rebase a reescribir la historia de su localidad consolidaciones, pero en una rama que no publicará de todos modos (por lo que no se hace daño).
Una vez que todas sus funciones nuevas estén funcionando, puede fusionar esa rama privada con la CABEZA actual de la rama de integración correspondiente.

La "rama privada - fusión o selección de cereza - rebase - resolución local - fusionar de nuevo" es un flujo de trabajo necesario, ya que varios equipos deberán fusionar su trabajo en una rama común. Deben reproducir lo que desean publicar en una rama privada antes de fusionarlo con la rama común, de lo contrario, cada equipo podría romper lo que representa el HEAD de la rama común.

Otros detalles en las preguntas:

• git commit frequency
• git releases management (otro flujo de trabajo de combinación)
• JC Hamano articles (gracias a Jakub Narębski)