remota - Ramificación y fusión de buenas prácticas en Git.

git merge español

Question

Tenemos un equipo de desarrolladores de 4 y nos hemos mudado recientemente a Git. Queremos aprender las mejores prácticas con respecto al flujo de trabajo con ramificación y fusión.

Estamos utilizando una versión ligera de Git Flow. Tenemos un desarrollo, una puesta en escena y una rama maestra que son lineales entre sí.

• La escenificación se ramifica del maestro
• dev es ramificado de la puesta en escena

Además de eso, utilizamos sucursales de características y revisiones para trabajar en nuevas características y corregir errores.

Tengo las siguientes preguntas:

1. ¿Deberíamos ramificar las ramas desde dev o desde master?
2. Cuando una rama de función está lista, ¿deberíamos combinar la rama de función en dev, luego fusionar dev en la preparación, o combinar la rama de función en la puesta en escena y luego la rama de función en el maestro?

Creo que deberíamos separarnos del maestro y fusionar la rama de características, porque podría haber algo en el desarrollo que quizás no queramos fusionar con la puesta en escena y el maestro.

¿Cuál es tu opinión? ¿Cuáles son las mejores prácticas?

Answer 1

Esto siempre depende de cómo quieres trabajar y del acuerdo del equipo. Dicho esto.

1. Una característica comienza desde la rama dev en su propia rama. Desde la rama maestra, solo se deben ramificar las revisiones, ya que la rama maestra siempre debe ser la versión estable de su software.
2. Cuando se realiza una rama de funciones , se debe combinar en dev , luego, en algún momento, se debe bifurcar su próxima versión de dev (incluidas algunas funciones) en una nueva rama ''release / *'' que se fusionará con la maestra una vez que se haya estabilizado y bien probado.

En la página de Atlassian tienes una muy buena explicación de este flujo de trabajo.

La idea general con este tipo de flujos de trabajo es tener una rama de versión estable en la que pueda trabajar y corregir cualquier error inmediatamente si lo necesita con la suficiente confianza de que seguirá siendo estable y que no se introducirá ninguna característica o refactorización nuevas sin darse cuenta.

También para tener aislamiento y libertad para cada nueva característica que se desarrollará en su propia rama sin ruido de otras características. Luego, finalmente, fusionará sus características en su rama dev y de allí en la rama maestra para la próxima versión.

Lo único que recomendaría para usted es aprender a volver a clasificar sus ramas de características en la parte superior de la rama de desarrollo cada vez que se fusiona otra característica en dev para evitar la resolución de conflictos en el tiempo de combinación, pero de forma aislada en la rama de características donde sabe qué tus cambios son

También parece que esta pregunta se hizo antes

Answer 2

Nos decidimos por un flujo de trabajo llamado Git Flow , pero en lugar de bifurcar las características de dev, las bifurcamos desde la versión actual. Esto nos permite trabajar en problemas separados en diferentes velocidades. Si tienen éxito en el control de calidad, entran en el lanzamiento.

En cuanto a sucursales y despliegue:

• La rama dev se implementa automáticamente en los servidores de prueba.
• La rama de la versión actual se implementa automáticamente en los servidores de ensayo.
• La rama maestra se implementa manualmente en servidores en vivo por el release-master.

El flujo de trabajo es el siguiente:

1. Cree una rama de lanzamiento desde el maestro al comienzo de cada lanzamiento / sprint, por ejemplo, lanzamiento / 2015-mayo .
2. Crear una rama dev desde lanzamiento / 2015-mayo
3. Trabajando en una nueva función, ISSUE_NUMBER desde el lanzamiento y ISSUE_NUMBER / ISSUE_NUMBER .
4. Trabaja en tu función.
5. Cuando esté listo para la prueba, fusionarlo en dev.
6. Si se acepta, fusionarlo en la rama de la versión actual.
7. Si no es aceptado, vaya al paso 4.
8. Cuando el lanzamiento esté listo, fusionarlo en el maestro

Después de que la versión se implementó en vivo y se descubrió un error crítico, ramificamos una rama de revisión de master (por ejemplo, hotfix / ISSUE_NUMBER ), lo ISSUE_NUMBER nuevo en master y lo implementamos nuevamente.

Answer 3

Si bien Git Flow es un excelente modelo de bifurcación, las preguntas que realiza son un síntoma de un problema mayor: Git Flow es demasiado pesado para un pequeño equipo que trabaja en un producto web para el consumidor (supongo que usted está trabajando en la web del consumidor producto, no dude en ignorar si está codificando la sala de control de la planta de energía nuclear).

Me gustaría animarle a que considere la implementación continua (CD) con un modelo de bifurcación extremadamente simple:

Es muy fácil configurar CD hoy en día:

1. Utilice Travis , CodeShip , Jenkins o un sistema similar para ejecutar un conjunto completo de pruebas y compilaciones en cada confirmación enviada en cada rama de su base de código
2. Configure Travis / Codeship / Jenkins para desplegar en producción cada confirmación para dominar que pase las pruebas.
3. Crea una nueva rama del master para cada nueva característica.
4. Codifica una nueva característica y pruébala en una rama.
5. Combina una rama de función en el master y mira cómo se activa.

Hay muchas objeciones comunes a esto, que todas se pueden resumir como "¡¿pero qué pasa si introduzco un error ?!". La respuesta es "¡Lo arreglarás!". Si escribe pruebas, si supervisa su sitio de producción, si realiza revisiones de códigos, si practica la programación en pares, si usa indicadores de características y mantiene sus características pequeñas, entonces los beneficios que obtiene del CD superarán los problemas ocasionales cualquier día.

Te animo a que lo intentes. Te liberará para que te concentres en lo que realmente importa: ¡construir un gran producto! Si no me crees, echa un vistazo a esta excelente presentación de Github .