¿Cuáles son algunos de los esquemas de ramificación/compromiso de vida más comunes de Git?

Question

En primer lugar, lo siento si se trata de un duplicado, pero traté de buscar y todo lo que pude encontrar fue información sobre cómo hacer ramas en Git y otras cosas. Eso no es lo que estoy buscando tanto; Estoy tratando de descubrir cómo las diferentes personas configuran sus ramas de Git para que coincidan con su flujo de trabajo.

Déjeme darle un ejemplo de cómo nuestra empresa lo hace:

1. desarrollador se compromete en su propia rama, localmente
2. desarrollador empuja comprometerse con su mando a distancia, donde un sistema de integración continua la comprueba y otro desarrollador revisa
3. Si la revisión/construir pases, la confirmación se fusionaron en una rama de control de calidad (si no funciona, se hacen más confirmaciones hasta que la revisión/construir pases)
4. Si la confirmación falla de control de calidad, una reversión cometer está hecho para sacarlo
5. Después de que las confirmaciones de QA estén listas, nuestra rama maestra recibe las confirmaciones (la rama de control de calidad se basa en ella, por lo que no se necesitan fusiones)
6. Las ramificaciones periódicas se toman de la rama maestra y se usan para liberar "en la naturaleza" ". Si se encuentran problemas aquí, una reversión cometer volverá a ser utilizado para eliminar el código
7. Después de un lanzamiento, los desarrolladores de rebase sus ramas en la rama principal (conseguir ambos sus confirmaciones sobre las previas y las de otros desarrolladores)

Ahora, hay algunos problemas con este sistema; Notaré algunos en los comentarios, pero realmente no estoy buscando "arregle nuestro sistema por favor", solo estoy tratando de ver qué otras opciones de ramificación podríamos usar en su lugar, para poder pesar el varias posibilidades.

Entonces, si ha trabajado en varias compañías que usan Git (o incluso mejor, si es una especie de consultor que ha visto montones de configuraciones de Git), ¿podría compartir: cómo las diferentes compañías configuran las sucursales de Git? (y mueve commits entre ellos) para facilitar las diversas etapas de desarrollo ... ¿todo mientras trata de ser lo menos molesto posible? Estoy seguro de que debe haber algunos patrones comunes ... pero no tengo idea de lo que son.

P.S. Si solo has visto una configuración de Git, pero crees que es interesante, por favor, publícala. Sin embargo, me gustaría otorgar la respuesta a quien ofrezca el mejor desglose de opciones posibles, y espero que venga de alguien que haya visto varias configuraciones de Git.

Answer 1

He estado administrando varios equipos ahora que están usando Git y hemos desarrollado una estrategia que funciona muy bien para nosotros.

• Master es SIEMPRE una copia de EXACTLY lo que está en producción. Cuando se libera el código, la rama actual se reenvía rápidamente al maestro, y se agrega una etiqueta para que la publicación se marque a tiempo y podamos tomar el código si alguna vez lo necesitamos.
• Los desarrolladores tienen la libertad de trabajar de la mejor manera en SUS ramas, sin embargo, para ramas de características, generalmente tenemos una rama para cada característica y varios desarrolladores se fusionan desde y hacia esa rama para compartir el trabajo en esa función.
• Cuando llega la hora de un candidato de lanzamiento, se crea una bifurcación RC_XXX y las bifurcaciones de la característica que están lo suficientemente lejos se fusionan en ella. Esto luego se prueba y las correcciones de errores se derivan de esto.
• Cuando todo está dicho y hecho, la rama RC_XXX se libera a la producción, y después de que se "pega" durante unos días, la promovemos a la maestra y las nuevas ramas de características se basan en ella.

Esto funciona muy bien, ya que las soluciones rápidas contra la producción son fáciles de crear e implementar simplemente ramificando desde el maestro, y los desarrolladores pueden ramificarse contra las ramas de características para obtener dependencias si es necesario.

Answer 2

¿Qué hay de esto (estoy haciendo caso omiso de lo que los desarrolladores tienen en su máquina):

• cada desarrollador ha aceptado una rama de parches (QA se compromete aquí), que está basado en el último punto de control principal (nueva rama para cada versión)
• cada desarrollador tiene una rama de parches a la espera de que se compromete en que se reajusta continuamente contra la rama parches aceptado (rama persistente)
• vez de control de calidad se realiza para todos los desarrolladores, todos los parches ramas aceptadas se combinan en master
• se crean nuevas ramas de control de calidad y todos los desarrolladores vuelven a tener una nueva base

Answer 3

"Después de un lanzamiento, los desarrolladores vuelven a establecer sus sucursales": ouch ...

No soy un consultor de Git (todavía), pero por experiencia, los desarrolladores deberían volver a basar su trabajo con mucha más frecuencia (que solo "justo después de un lanzamiento").
De lo contrario, como mencionas en tu comentario, eso conduce a un montón de "git revert" (que funciona, pero debe seguir siendo una ocurrencia excepcional en lugar de una solución común).

La colaboración punto a punto es posible pero implica un poco de disciplina como es requires setting up a bare repo y local protocol.