La forma más segura de rebase de una rama pública
¿Cuál es la forma más segura de hacer un rebase en una rama pública, es decir, causando la menor cantidad de problemas para todos los que la utilizan? ¿O hay una mejor alternativa?
Mi equipo es nuevo en el uso de git y me han pedido ayuda para organizar su repositorio. Tienen una rama principal que está muy desactualizada y todo el trabajo se está haciendo en una rama llamada dev (con ramas derivadas de dev para cada nueva característica).
Acabamos de lanzar FEATURE_X y el trabajo acaba de continuar en la rama dev para la característica FEATURE_Y. Planeo fusionar todos los commits de dev hasta FEATURE_X en la rama principal. Las características son grandes lanzamientos de software, hay miles de commits tanto en dev como en la rama principal.
Mi problema es qué hacer con la rama dev:
- En primer lugar, planeo fusionar dev hasta el commit FEATURE_X en la rama principal, para que la HEAD de la rama principal esté en FEATURE_X.
-
Luego me gustaría hacer un rebase de dev sobre la rama principal, de modo que el historial de los commits de dev comience en el commit después de que se haya lanzado FEATURE_X. Creo que esto limpiará el historial de dev, lo hará menos difícil de trabajar y causará menos problemas cuando se complete FEATURE_Y y sea necesario fusionar dev nuevamente en la rama principal. Según puedo entender, también es ideal no seguir trabajando en una rama después de haberla fusionado.
Sin embargo, todos los consejos que encuentro dicen que no se debe hacer un rebase en una rama pública. Ya tenemos varios desarrolladores trabajando activamente con la rama dev para implementar características para RELEASE_Y.
Este artículo http://git-scm.com/book/en/v2/Git-Branching-Rebasing sugiere que si tienes que hacer un rebase en una rama pública, debes informar a todos y hacer que utilicen git pull –rebase. ¿Alguien tiene experiencia con esto o tratar de organizar dev es más complicado de lo que vale la pena?
davy.ai
Hacer un rebase en una rama pública puede ser arriesgado y causar conflictos para otros desarrolladores que trabajan en la misma rama. Sin embargo, en este escenario, puede ser beneficioso ordenar la rama de desarrollo realizando un rebase sobre la rama principal. Para minimizar el impacto en otros desarrolladores, sería mejor comunicarse con el equipo de antemano y hacerles saber sobre el plan de rebase. Además, sería útil proporcionar orientación sobre cómo usar correctamente “git pull –rebase” para asegurarse de que la rama de desarrollo local de cada desarrollador esté actualizada y alineada con la rama pública rebasada. Otra alternativa podría ser crear una nueva rama a partir de dev, realizar un rebase de esa nueva rama sobre master y hacer que los desarrolladores cambien y trabajen en la nueva rama en su lugar. En última instancia, la decisión depende de las especificaciones del flujo de trabajo del equipo y los posibles riesgos y beneficios de cada enfoque.