La convención de Git para indicar tirar twigs

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.

  • ¿Hay una convención de nomenclatura aceptada para las sucursales que indique que, aunque empujada, esta twig puede estar completamente anulada? Una forma para que la persona A indique que "si sacas provecho de esto, no puedo garantizar la felicidad continua" .
  • ¿O hay incluso una forma (command) en git que me permite clasificar twigs como tirar?
  • ¿Es simplemente que nunca, independientemente de las circunstancias, acepta alterar un historial de git si alguien podría haberlo sacado?
  • ¿Debería la persona A haberse tomado el time para configurar adecuadamente su estación de trabajo para permitirle a la persona B sacarla directamente de él? Por lo tanto, ir en la oscuridad, no dejar que nadie sepa en qué están trabajando.
  • Tal vez la única solución viable es una buena comunicación pasada de moda; solo hablamos con ustedes, compañeros.

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.

actualización (respuesta a los comentarios).

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:

  • solo lectura
  • solo actualizado por un administrador.

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.