¿Por qué ocurre un conflicto solo para una confirmación en lugar de dos en mi operación de rebase?

TL; DR

Solo se produce un conflicto al comienzo de la operación de rebase. Debido a la forma en que resuelve ese conflicto, el segundo parche se aplica limpiamente; no hay causa para conflictos adicionales.

Más detalles

Para completar, aquí está cómo recrear una versión simplificada de su ejemplo de juguete desde la línea de command; He acortado las líneas en file.txt un poco, para mayor comodidad:

 mkdir rep1 cd rep1 git init printf "l1\nl2\n" > file.txt git add touch.txt git commit -m "initial commit" cd .. git clone rep1 rep2 git remote rename origin rep1 # for clarity cd rep2 sed -i '.txt' 's/l1/l1rep2/' file.txt git commit -am "append 'rep2' to first line" sed -i '.txt' 's/l2/l2rep2/' file.txt git commit -am "append 'rep2' to second line" cd ../rep1 sed -i '.txt' 's/$/rep1/' file.txt git commit -am "append 'rep1' to both lines" cd ../rep2 git fetch 

Después de todos esos commands, su repo rep2 ve de la siguiente manera (el contenido de file.txt se muestra debajo de cada confirmación):

Ahora, en rep2 , corres

 git rebase rep1/master 

Para comprender lo que sucede durante esta rebase, recuerde que una rebase es poco más que una serie de operaciones de selección de cereza, seguidas de algunas reorganizaciones de twigs; esto está bien explicado en el tutorial Think as a Git .

Primero, Git intenta reproducir el "parche A -> B " sobre el compromiso D Sin embargo, Git no puede aplicar este parche limpiamente; En términos generales, Git, por sí solo, no tiene forma de averiguar qué versiones de las dos líneas se supone que debe mantener:

Sin saber qué hacer, Git le pide que resuelva el conflicto, lo que hace reemplazando el contenido de file.txt por

 l1-rep2 l2 

(lo cual es polémico, porque eso crea una fusión maligna , como señala Daniel Böhmer en su comentario ). Luego escenificas y comprometes los cambios:

 git commit -am "conflict resolution" 

Ahora ejecuta git rebase --continue , y Git luego intenta reproducir el parche " B -> C " encima de confirmar E … ¡y tiene éxito ! Ese parche se aplica limpiamente; Debido a que los contenidos de file.txt en commits B y E son idénticos, no hay motivo para ningún conflicto aquí, y terminas con

Al mirar tus capturas de pantalla, no obtuviste el conflicto en tu segunda confirmación aplicada. Verifique los cambios-> Registro de su PhpStorm y verá dos confirmaciones en la parte superior del remote/master . O tal vez incluso tres, a juzgar por la salida de su git

 Applying: rep2-commit 2 Applying: rep2-commit 3 

Editar

La razón por la que no se generó conflicto por segunda vez es porque la fusionó para que el file esté exactamente en el estado de rep2-commit 2 . Si elige realizar cambios en rep1, tendría conflictos mucho más allá.

Mis dos centavos. Justo antes de iniciar la rebase, tenías algo así como:

A--B--C--D--E rep2 \ F rep1

Después de la rebase, obtienes

A--B--C \ F--D'--E' rep2

¿Derecha?

De la documentation de git rebase , entiendo que el contenido de commits D y E se guarda primero en un área temporal. Commit D se aplica por primera vez además del compromiso F, generando un conflicto. Al final de la resolución del conflicto, se crea el compromiso D '. Luego, se aplica el compromiso E sobre el compromiso D '. Commit E es la modificación de la línea 2 en file.txt después del commit D. Entonces mi punto es: resolución de conflictos para generar D 'es el paso crítico. En function de la elección realizada, el file de contenido.txt para la confirmación D 'es igual al contenido de file.txt en la confirmación D. En ese caso, no habría ningún conflicto al tratar de generar E' además de la confirmación D.