Guión:
La persona A crea una twig experimental para resolver un problema. La persona B se interesa y quiere verificar el código, debido a la pereza que la persona A empuja a su github en lugar de configurar su estación de trabajo para que la persona B la retire directamente de él.
A y B están pirateando, la persona C ve la actividad en github y clones, ansiosa por ver qué está pasando. Mientras tanto A y B concluyen que es una solución horrible y elimina la twig . Pero la persona C logra convertir la idea en algo grandioso y quiere compartir. La fusión del infierno comienza cuando la twig de C ya no tiene un ancestro común con su objective de fusión.
Es curioso ver cómo se debería haber manejado este escenario.
Y si todo lo demás falla, ¿cuál es la estrategia adecuada para la persona C en este caso? ¿Cómo se pueden aplicar los cambios correctamente cuando su trabajo se realiza en un gráfico desconectado?
La fusión del infierno comienza cuando la twig de C ya no tiene un ancestro común con su objective de fusión.
Seguramente, la twig maestra de A tiene un ancestro (en su historia) en la twig eliminada.
C puede empujar la twig hacia github donde A puede tirar de ella nuevamente. ¿Qué está mal con eso? o, C puede hacer la combinación / rebase en una nueva twig (sobre el maestro de A) y, de nuevo, dejar que A le quite de él.
Eliminar una twig en realidad no reescribe el historial, al less no de una manera incorrecta que impida la fusión.
Supongo que la persona A tenía este tipo de historia:
a--b--c--d--e--f--g master | x--y--z experiment Entonces, después de eliminar la twig, todavía tiene los commits de aa c, probablemente se parece más a:
a--b--c--d--e--f--g--h--i--j--k master
La persona C presumiblemente tiene:
a--b--c--d--e--f--g master | x--y--z--w--v--q experiment
Este es un escenario perfectamente razonable donde la fusión no debería ser tan mala.
Por ejemplo, la persona C puede extraer del maestro de A y fusionar el experimento en él.
Aún no hay una convención formal.
Un buen ejemplo de sucursal desechable (mencionado en este artículo en Git rebase de marzo de 2010) es branch pu de git.git .
Los detalles de preguntas frecuentes de Git :
La twig "pu" a menudo no avanzará rápidamente porque algunos commits se han eliminado por completo desde la última vez que pulsaste.
Si desea rastrearlo, agregue un signo más (+) a la línea correcta en su file
.git/config, como este:
[remote "origin"] fetch = +refs/heads/pu:refs/remotes/origin/pu
Lo que le dice a git que se encargue del problema simplemente saltee la verificación de avance rápido ( sobrescribiendo su reference anterior con la nueva ).
O simplemente puede eliminar esa línea por completo si no desea rastrear la twig pu en absoluto.Es posible que en versiones futuras de git podamos marcar algunas twigs "esto se espera que se rebobine" explícitamente y hacer que la operación de clonación tome nota, para darle el signo más automáticamente.
Así que una idea es evitar activamente (a través de los ganchos) cualquier impulso a esas twigs desechables que los hacen:
Cada mantenedor es responsable de su propio tenedor. No puedes asumir que otro committer haya cometido o no algo grande.
Puede ver información si el autor y el autor no son la misma persona.
Si no quieres un parche, puedes revertirlo en tu propio tenedor.