Actualmente, nuestra empresa está utilizando un modelo de ramificación simple de troncal / lanzamiento / revisión y desea recibir asesoramiento sobre qué modelos de ramificación funcionan mejor para su empresa o proceso de desarrollo.
Flujos de trabajo / modelos de ramificación
A continuación se encuentran las tres descripciones principales de esto que he visto, pero se contradicen parcialmente entre sí o no van lo suficientemente lejos como para resolver los problemas posteriores que hemos encontrado (como se describe a continuación). Por lo tanto, nuestro equipo hasta el momento utiliza soluciones no tan buenas. ¿Estás haciendo algo mejor?
Fusión vs rebase (historia enredada vs secuencial)
¿Debería uno
pull --rebase
o esperar con la fusión a la línea principal hasta que su tarea haya finalizado? Personalmente, me inclino por la fusión, ya que esto conserva una ilustración visual de en qué base se inició y finalizó una tarea, e incluso prefieromerge --no-ff
para este propósito. Sin embargo, tiene otros inconvenientes. Además, muchos no se han dado cuenta de la propiedad útil de la fusión: que no es conmutativa (fusionar una rama de tema en maestro no significa fusionar maestro en la rama de tema).Estoy buscando un flujo de trabajo natural.
Algunas veces los errores ocurren porque nuestros procedimientos no capturan una situación específica con reglas simples. Por ejemplo, una solución necesaria para versiones anteriores debería, por supuesto, basarse lo suficientemente corriente abajo como para ser posible fusionarla en todas las ramas necesarias (¿es lo suficientemente claro el uso de estos términos?). Sin embargo, sucede que una solución llega al maestro antes de que el desarrollador se dé cuenta de que debería haberse colocado más abajo, y si eso ya se ha empujado (aún peor, fusionado o algo basado en él), la opción restante es la selección de cereza, con Sus peligros asociados. ¿Qué reglas simples como esas usas?También en esto se incluye la incomodidad de una rama temática excluyendo necesariamente otras ramas temáticas (suponiendo que se ramifiquen a partir de una línea de base común). Los desarrolladores no quieren terminar una característica para comenzar otra sintiendo que el código que acaban de escribir ya no existe.
¿Cómo evitar crear conflictos de fusión (debido a la selección de cereza)?
Lo que parece una forma segura de crear un conflicto de fusión es elegir entre ramas, ¿nunca se pueden volver a fusionar? ¿Aplicar la misma confirmación en revertir (¿cómo hacer esto?) En cualquier rama posiblemente resolvería esta situación? Esta es una razón por la que no me atrevo a impulsar un flujo de trabajo basado en gran medida en la fusión.
¿Cómo descomponerse en ramas tópicas?
Nos damos cuenta de que sería increíble reunir una integración completa a partir de ramas temáticas, pero a menudo el trabajo de nuestros desarrolladores no está claramente definido (a veces tan simple como "hurgar") y si algún código ya ha entrado en un tema "misceláneo", no se puede sacar de allí nuevamente, de acuerdo con la pregunta anterior? ¿Cómo trabaja con la definición / aprobación / graduación / liberación de sus ramas temáticas?
Por supuesto, los procedimientos adecuados, como la revisión del código y la graduación, serían encantadores.
Pero simplemente no podemos mantener las cosas lo suficientemente desenredadas para manejar esto, ¿alguna sugerencia? ramas de integración, ilustraciones?
A continuación se muestra una lista de preguntas relacionadas:
- ¿Cuáles son algunas buenas estrategias para permitir que las aplicaciones implementadas sean reparables?
- Descripción del flujo de trabajo para el uso de Git para el desarrollo interno
- Flujo de trabajo de Git para el desarrollo corporativo del kernel de Linux
- ¿Cómo mantiene el código de desarrollo y el código de producción? (¡gracias por este PDF!)
- gestión de lanzamientos de git
- Flujo de trabajo de Git Cherry-pick vs Merge
- Cómo seleccionar múltiples confirmaciones
- ¿Cómo fusionar archivos selectivos con git-merge?
- Cómo elegir una variedad de confirmaciones y fusionarse en otra rama
- Flujo de trabajo de ReinH Git
- flujo de trabajo de git para realizar modificaciones que nunca volverá a empujar al origen
- Cherry-pick una fusión
- ¿Flujo de trabajo de Git adecuado para SO combinado y código privado?
- Proyecto de mantenimiento con Git
- ¿Por qué no puede Git fusionar cambios de archivos con un padre / maestro modificado?
- Buenas prácticas de ramificación / rebase de Git
- ¿Cuándo "git pull --rebase" me meterá en problemas?
- ¿Cómo se usa DVCS en equipos grandes?
También revise lo que Plastic SCM escribe sobre el desarrollo impulsado por tareas , y si Plastic no es su elección, estudie el modelo de ramificación de nvie y sus scripts de soporte .