Git Cambia a file perdido después de fusionarse con control remoto (SourceTree, GitHub)

Recientemente, he recibido múltiples ocasiones de varios equipos de que se están perdiendo ciertos cambios después de fusionarnos con nuestro repository de origen en GitHub.com. Los miembros del equipo están utilizando SourceTree como su cliente de git.

El hilo común que he encontrado es que parece que el repository piensa que el file parece tener un número X de confirmaciones en la twig antes de la fusión y luego confirma XY después de la fusión. Al mirar el logging de compromiso de la sucursal, las confirmaciones continúan allí, pero por alguna razón no se aplican al file en cuestión. En el tree de Fuentes, esto es lo mismo, pero si "Sigue los files renombrados", trae todas las confirmaciones. No hubo absolutamente ningún cambio en el nombre del file o la estructura de la carpeta.

¿Qué podría estar pasando aquí?

https://www.dropbox.com/s/zrcb9tw2ptpb3b0/FileHistory_Commit.png?dl=0 https://www.dropbox.com/s/uc5v5d2bfztoicn/FileHistory_Develop.png?dl=0

Es importante tener en count que los commit de git no están vinculados a files específicos, y no están definidos por diffs; cada confirmación es simplemente una instantánea de todo el repository. Por lo tanto, cuando observa el "historial" de un file, depende de la herramienta que esté utilizando decidir cuál se compromete a "asociar" ese file. Esto normalmente se hace de la manera obvia: si la versión de un commit de un file es diferente a la versión del file del commit del padre, esa confirmación se incluye en el historial del file.

Donde las cosas se complican es cuando un compromiso tiene más de un padre, es decir, en una fusión. Normalmente, no desea verlos en el historial de un file si hay diferencias con solo uno de los padres. Para ver por qué, considere el caso común en el que realiza el cambio X en una bifurcación, confírmelo en la confirmación A, y luego, luego, fusione esa bifurcación en maestro con confirmación G. Si observa una diferencia entre G y su padre primario, usted verá el cambio X. Pero eso no es donde X fue "realmente" introducido; eso sucedió en la confirmación A. Entonces, cuando se mira el logging del file, no se quiere ver la confirmación G, solo se desea ver la confirmación A. La exception a esto es cuando se resuelven los conflictos; en ese caso, un cambio sería realmente introducido por la fusión misma. Esto se indicaría por ser un diff en el file en comparación con los padres primarios y secundarios. Cuando hace clic en "Seguir files renombrados", SourceTree parece include los commit de fusión, aunque no tiene nada que ver con los files renombrados.

Ahora todo está bien y elegante cuando las fusiones se realizan correctamente. En su caso, sin embargo, tiene algunas fusiones fallidas, es por eso que los commits se están perdiendo. Su informe es privado, por lo que no puedo verlo y decirle con precisión qué combinaciones se fracasaron y cómo, pero esto es lo que probablemente sucedió. Un desarrollador hizo un git pull que resultó en conflictos de combinación, lo que impidió la confirmación automática que generalmente ocurre con pulls / merges. Junto con los files en conflicto, el desarrollador vio cambios en su área de preparación que no hicieron. Supusieron que no querían realizar cambios aleatorios, por lo que deshicieron esos cambios , corrigieron sus conflictos de fusión y se comprometieron.

Son esos mismos cambios que deshicieron los que ahora están "perdidos". Cuando comete una fusión, promete que la instantánea que está cometiendo contiene todos los cambios a los que pueden acceder ambos padres. Esto significa que cuando haces un diff de una combinación correcta con su primario primario (que es lo que el desarrollador ve cuando SourceTree list "files modificados"), deberías ver todos los cambios introducidos por el padre secundario.

El resultado final es el siguiente: cuando se encuentra en medio de una fusión y ve cambios que no aparecieron de repente, debe confirmar esos cambios o cancelar la fusión .