¿Siempre es malo volver a basarse en una sucursal pública?

Answer 1

Bastante mucho

A veces puede salirse con la suya, si está en comunicación constante con todos los demás consumidores de una sucursal compartida, pero introduce una gran cantidad de comunicación innecesaria y un potencial de frustrante reelaboración por parte de aquellos que no estaban al tanto de su intención de reabastecerse. La práctica no se extenderá más allá de pequeños grupos de desarrolladores que mantienen contacto en tiempo real todo el tiempo que trabajan, por lo que no es un buen hábito acostumbrarse.

Si el propósito de refactorizar una rama compartida es producir un historial simplificado para un árbol final que sea más fácil de digerir y analizar que el historial publicado originalmente, entonces una alternativa podría ser clonar la rama, volver a crear la base del clon y (siempre que aún sea árbol-igual al original), fusione el clon con el original. La intención aquí es no cambiar el árbol final, sino aplastar, dividir o reorganizar los compromisos en la historia que condujo al árbol final con el propósito de mejorar la comprensión de la rama por parte de los revisores.

Si las dos ramas en la combinación son iguales a los de un árbol, entonces la combinación estará libre de conflictos y una rama tendrá el historial feo y la otra rama tendrá el historial saneado. Si se requiere un mayor desarrollo en la rama, lo ideal sería que se realizara como compromiso con el historial saneado que se fusiona nuevamente, como se requiere en la rama original. Cualquier persona que haya realizado un trabajo basado en el historial feo original puede rebautizar las confirmaciones hechas después de la divergencia del historial original a la fusión con el historial limpio o al historial limpio mismo. Los únicos conflictos que tendrán que resolver en este caso son los conflictos estrictamente resultantes de la divergencia de la rama original, un hecho de la vida con control de versiones distribuido, no tendrán que lidiar con conflictos causados ​​únicamente por la actividad de rebasado.

De esta manera, obtiene la mayoría de los beneficios de la rebasación (por ejemplo, un historial más fácil de analizar, aunque con una rama fea que puede ignorar) sin la mayor parte del costo de los conflictos de fusión en gran parte innecesarios y un tanto inútiles causados ​​por la reorganización indisciplinada de ramas compartidas.

Answer 2

La razón por la que no debe cambiar la base de una rama que vive en el repositorio central es que no podrá hacer “git push”. Git push solo avanza rápidamente todas las sucursales con sus cambios locales. Sin embargo, no funciona si modificaste el historial (es decir, si hiciste una rebase). En este caso, necesitará “git push –force”. Esto funcionará, pero dejará confirmaciones duplicadas en el repositorio central. Además, muchos repositorios desactivan la fuerza de empuje, por lo que no puedes hacer eso.

Si es el propietario del repositorio central y la fuerza de empuje no está deshabilitada, teóricamente puede hacerlo, pero no es una buena práctica. La fusión es menos de un dolor de cabeza.

Para obtener una respuesta técnica más detallada sobre por qué el impulso normal no funciona, consulte Git empuje rechazado después del reajuste de la función.