Git elige el ancestro equivocado

Estoy usando git con algunas otras personas. Tenemos un repository central y luego twigles de seguimiento local. Recientemente, nos hemos topado con un problema en el que git piensa incorrectamente que el último ancestro común se ha comprometido de la twig principal y la nueva twig es una confirmación que solo se realizó después de que creamos la nueva twig, lo que provocó cambios cuando se fusionaron la nueva twig de nuevo. Un ejemplo:

Alice hace algunos cambios en su copy local de la twig principal y los compromete, pero no los empuja. Digamos que ella cambia la primera línea del file foo.txt.

Bob saca de la copy central de la twig principal. Por lo que él puede decir, él está actualizado.

Ambos continúan trabajando. En algún momento, Alicia empuja. Más tarde, Bob llama a Git Log y ve que su twig es supuestamente un antepasado del commit en el que Alice cambió a foo.txt, a pesar de que nunca sacó sus cambios. Cuando Bob se fusiona, como era de esperar, los cambios de Alice han desaparecido.

No he podido reproducir esto, pero puedo decir a partir de los loggings que sucedió en un punto (es decir, tenemos una twig que supuestamente es un sucesor de una confirmación en la que se realizaron cambios en un file fuente, pero en el que los cambios no estaban presentes). ¿Cómo es posible este tipo de cosas, y cómo puedo detenerlo?

¿Alguien en algún momento empujó forzosamente algunos cambios y sobreescribió un commit hash específico (usando -f en push)? Eso suena como si tu caso pudiera ocurrir con esto.

Si eso puede ayudarlo, nuestro flujo de trabajo en el trabajo es usar siempre rebase al tirar / empujar:

La persona A ha hecho cambios y los empuja.

La persona B sigue trabajando, haciendo compromisos locales

En algún momento, la persona B quiere presionar en vivo. Para hacer eso.

  • Persona B asegúrese de que la sucursal local esté limpia (escondite si no).

  • La persona B ejecuta git pull –rebase (esto downloadá todos los cambios y volverá a aplicar los suyos encima de la nueva HEAD)

  • Si hay algún conflicto, la Persona B resuelve conflictos.

  • La persona B finalmente empuja la copy local en vivo.

Y vuelva a aplicar el mismo process, siendo la persona A la que está detrás del origen y necesita extraer la base

Y NUNCA use -f cuando lo presione en vivo, es realmente malo.

Más información: Un empuje de fuerza es tentador cuando, por ejemplo, la persona A hizo una confirmación, la lanzó en vivo y luego se dio count de que había un error. La persona A hace una enmienda al último compromiso. La única forma de impulsar ese compromiso en vivo es hacer un push -f … y eso es realmente malo para las personas que trabajan en sus propias copys y que han realizado confirmaciones locales para su copy y presentación en vivo.