Cómo abordar los conflictos de estrategia de unificación con nuestro flujo de trabajo de Git
He visto muchas preguntas similares aquí, pero ninguna respondió nuestro problema específico. Mi pregunta es en realidad sobre las estrategias de fusión, pero primero tengo que describir nuestro flujo de Git.
He leído muchas prácticas recomendadas para un flujo de Git ideal, pero nada de lo que encontré fue perfectamente adecuado para nuestras necesidades. Así que podríamos estar usando una metodología no ideal.
Aquí está el flujo:
Tenemos una rama de master, alineada con el entorno de producción. Tenemos una rama de releasable para probar el paquete de lanzamiento en un entorno de preproducción con datos realistas. Tenemos una rama de stable para pruebas en un entorno estable. Y cuando comenzamos a trabajar en una nueva función, creamos una rama de feature desde master. Cuando se completa la función, la fusionamos a stable a través de una solicitud de extracción. Aquí está el problema; muchas funciones se cancelan después de completar las pruebas o tienen que esperar futuras versiones, por lo que tenemos que ramificarnos desde master porque no queremos que esas funciones estén en nuestras nuevas ramas. Por esa razón, tampoco podemos fusionar stable con releasable. Entonces, si la función está lista para continuar, fusionamos la rama de feature a releasable a través de otra solicitud de extracción. Ahora, hay una confirmación diferente entre stable y releasable debido a las confirmaciones de fusión. Después de que el paquete esté listo para implementarlo, fusionamos releasable con master. Aquí viene mi problema; cuando creamos una nueva rama de feature desde master para comenzar a trabajar en una nueva función, tiene un historial de confirmación ligeramente diferente a stable. Debido a esta diferencia, a veces todos los cambios de archivo aparecen en la diferencia entre la rama de feature y stable, aunque son idénticos en contenido.
Estamos usando Bitbucket. He considerado usar -ff en lugar de –no–ff en solicitudes de extracción, pero tampoco quiero perder confirmaciones de fusión. También he considerado usar Rebase, merge (rebase + merge –no-ff) en la estrategia de fusión en Bitbucket, pero no estoy seguro de que resuelva nuestro problema de no tener una solicitud de extracción limpia.
Para resumir, necesito tener solicitudes de extracción limpias a stable con solo los cambios que se hacen en esa feature rama sin tener que sacrificar demasiado.
Cualquier ayuda sería apreciada.
davy.ai
Pregunta sobre el flujo de trabajo y estrategias de fusión de Git
La situación
El usuario ha descrito su flujo de trabajo de Git que incluye una rama maestra, una rama lanzable, una rama estable y ramas features para nuevas funcionalidades. Las funcionalidades son fusionadas con estable para su prueba y luego fusionadas con lanzable para empaquetar y desplegar. Cuando se crea una nueva rama feature desde maestro, tiene un historial de commits ligeramente diferente a estable debido a los commits de fusión. Esto hace que todos los cambios de archivo aparezcan en la diferencia entre la rama feature y estable, incluso si tienen contenido idéntico. El usuario busca una estrategia de fusión que resulte en pull requests limpios hacia estable con solo los cambios hechos en una rama feature específica.
Soluciones propuestas
El usuario ha considerado usar la bandera -ff en lugar de –no-ff en los pull requests, pero no quiere perder los commits de fusión. También ha considerado utilizar Rebase, merge (rebase + merge –no-ff), pero no está seguro de si resolverá el problema de tener un pull request limpio.
Recomendaciones
Dada la descripción del flujo de trabajo del usuario, la mejor estrategia de fusión para permitir pull requests limpios con solo los cambios hechos en una rama feature específica sería utilizar Squash and Merge. Este método permite que todos los cambios hechos en una rama feature específica se fusionen en un solo commit, lo que resulta en un pull request limpio hacia estable con solo los cambios realizados en esa rama. Este método es particularmente útil para ramas feature que no son necesarias en el código final.
Si el usuario todavía desea mantener el historial de fusión de sus ramas feature, podría considerar usar Merge Commit, que conserva los commits individuales realizados en la rama feature, pero aún resultaría en un pull request limpio hacia estable. Este método resultará en un historial de commits ligeramente más desordenado, pero mantendrá la integridad de la rama feature.
En general, se recomienda que el usuario experimente con diferentes estrategias de fusión para determinar cuál funciona mejor para sus necesidades específicas.