¿Puede una fusión cambiar el historial de confirmaciones de una sucursal?

Aparentemente puede, mira aquí , al less esta es la forma en que lo veo.

Antes de fusionarse. El master sucursal remota en el origin está a la izquierda. Ambas twigs son iguales.

enter image description here

Ahora supongamos que tanto mi amigo como yo hemos hecho algún trabajo, y mi amigo llevó su trabajo primero a la sucursal remota, y he comprometido mi trabajo localmente.

enter image description here

En este caso, no puedo simplemente git push , porque eso haría que commited by other lo eliminaran del repository remoto (creo que podría hacer `git push -f 'para eso, pero de nuevo, eso sobrescribiría la confirmación de mi amigo).

El artículo sugiere que el git pull origin master (que fetch los cambios de la twig master del repository de origin y lo merge en mi twig master local) reescribe el historial de confirmaciones en mi twig master local. ¿Cómo puede ser? Pensé que una fusión solo podía crear una nueva fusión de compromiso, sin alterar las confirmaciones existentes. Pero en este caso, el order de los compromisos ha cambiado; ahora lo primero es el commited by other , luego mi local commit .

Entonces, sabiendo que pull es lo mismo que fetch (que actualiza el origin/master twig de rastreo remoto que está almacenado localmente en mi PC) seguido de combinar el origin/master actualizado en el master twig local, ¿produciría el mismo resultado en este caso – ¿esa fusión alteraría el order de las confirmaciones pasadas en la twig master local?

enter image description here

Pero en este caso, el order de los compromisos ha cambiado; ahora lo primero es el cometido por otro, luego mi compromiso local.

Esto no es cierto: su compromiso local y el "cometido por otro" son compañeros o hermanos. El nuevo commit de fusión los tiene a ambos como padres. ¿Tiene sentido? Su historial de confirmaciones no cambia en lo más mínimo.

Parece que no puedo acceder al sitio que publicaste, pero el título en la url se refiere a la fusión y el rebase , y evitar el "infierno de rebase". Rebase realmente cambia tu historia; tal vez eso es lo que el autor estaba hablando.

Edite en respuesta al comentario : si tiene ABC localmente y ABD en el control remoto, después de search y fusionar su location local se verá así:

 A--B--C--M \--D-/ 

En otras palabras, tanto C como D tendrán B como padre, y tanto C como D serán padres de M Después de presionar, la twig remota también se verá así.

Ahora, al principio, puedes pensar, "entonces mi historia cambia, porque B solía tener un hijo, y ahora tiene dos". Pero git no almacena pointers a los niños, solo almacena pointers a los padres. Y C todavía tiene el padre soltero B , por lo que su historia no cambió. Y dado que D todavía tiene el padre único B , el historial del control remoto tampoco cambió.

Lo que David dijo es cierto, los dos commits son hermanos y el commit de fusión es su hijo. Sin embargo, si quieres una funcionalidad donde la confirmación remota se despliega "debajo" de tu confirmación local, puedes hacer git pull --rebase que desplegará todas las confirmaciones remotas y luego reproducirá las tuyas encima de ellas sin la confirmación de fusión.

Una fusión toma dos o más twigs, y crea un compromiso que intercala los cambios en todos los padres (resolviendo conflictos, según sea necesario, el usuario tiene que decidir cómo). git no cambia la historia por sí mismo.

Para cambiar el historial, debes solicitarlo explícitamente, a través de git rebase u otros commands explícitamente diseñados para dicha cirugía. No hace falta decir que son peligrosos y deben usarse con sumo cuidado.