¿Git tira commits invertidos en master?

Un colega, al que llamaremos Aaron, fue asignado para renovar una sección de un website como un proyecto a largo ploop. Él creó una nueva twig de Git, llamada aaron . Todos sus cambios fueron hechos en esta twig. Mientras él estaba trabajando, continué manteniendo el sitio como un todo, comprometiendo mis cambios como master .

Eventualmente, Aaron fusionó su twig en master . Esto de alguna manera revirtió todas las confirmaciones que había hecho para master entre el momento de la fusión y el momento en que se creó por primera vez la twig de aaron . Si git show <hash of merge commit> , puedo ver diferencias para cada file que modifiqué mientras Aaron trabajaba en su sucursal. Esas diferencias muestran una reversión de cada cambio que hice. Se ve de la manera en que lo haría si Aaron hubiera copydo manualmente el contenido de cada file de su twig en el master y hubiera realizado los cambios. (No hizo esto. Solo bash ilustrar lo que muestra el logging).

Según Aaron, él no hizo nada raro. Él dice que acaba de ejecutar git pull origin/aaron .

¿Qué pudo haber causado esto? ¿Es posible que el git pull origin aaron haya revertido todos mis cambios al master ?

Además, ¿hay alguna manera fácil de restablecer mis cambios al maestro sin revertir todo su trabajo?

EDIT 1:

Uno de los files que se cambió en el master y luego se revirtió después de la fusión fue foo.txt . Entonces hice esto:

 git checkout aaron git log foo.txt 

El logging no refleja ningún cambio en foo.txt después del momento en que se creó la twig de aaron . Esperaba ver una reversión de mis cambios en algún lugar del logging de la sucursal de aaron , pero no fue así. Entonces, ¿esta es la testing final de que Aaron hizo algo más que la simple atracción que afirma haber hecho?

EDICION 2:

Yo había dicho que había escrito origin/aaron , pero en realidad escribió el origin aaron . Lo he cambiado arriba.

EDIT 3

Según las sugerencias a continuación, elegí resolver esto reescribiendo el historial. Estoy en este punto convencido de que el problema fue causado por un bash equivocado de resolver conflictos.

La única forma de que git pull origin/aaron haga esto es si tuvo una fusión de master en aaron primero, que descartó todos los cambios en master (quizás usando git merge -s ours master ).

Ve a ver el historial. ¿Hay alguna fusión previa de master en aaron ? ¿Y descartan los cambios del master ? Si no hay ninguno, entonces la única explicación es que no ejecutó git pull origin/aaron .

En cuanto a la reinstallation de los cambios, podría retroceder su fusión y volver a crearla usted mismo. Eso va a modificar la historia, pero si estás de acuerdo con eso, es la solución más fácil. Si no estás de acuerdo con eso, entonces se vuelve un poco más complicado. En ese caso, querrás crear una twig temporal, retroceder su fusión y volver a fusionarse correctamente. Luego regrese a master y ejecute git read-tree tempbranch . Esto actualizará su índice con los resultados de su fusión temporal correcta [1], y luego podrá confirmar esto.

[1]: tenga en count que esto no modificará su tree de trabajo, por lo que querrá seguir con algo como el git checkout -- . .

Dado que todos los cambios ocurrieron en el compromiso de fusión, estás viendo lo que se conoce como fusión maligna. man gitglossary define de esta manera:

  evil merge An evil merge is a merge that introduces changes that do not appear in any parent. 

Hay una explicación de lo que esto significa en esta respuesta . Lo importante que debe saber es que esto no es algo que Git haga por sí mismo. Crear una fusión malvada requiere la intervención humana de alguna manera.

Lo que típicamente he visto que sucede es cuando alguien se fusiona y se confunde debido a conflictos. Por ejemplo, una cosa que podría haber causado esto es si Aaron comenzó su atracción, se vio abrumado por conflictos y decidió que era seguro resolver los conflictos copyndo sus files sobre los files existentes. Cuando él hace la fusión se compromete después de hacer esto, verá exactamente esto.

En cuanto a arreglarlo, haría lo que sugirió Kevin Ballard si puedes. git -reset --hard the master branch volver a cómo se veía antes de la fusión y luego rehacer la fusión.