GIT: ¿Qué es la prioridad de los commits durante la fusión?

Me pregunto, ¿cuál es la prioridad de elegir compromisos durante la fusión en la situación, que se describe a continuación?

He develop sucursal.

 D1 - D2 - D3 

Luego creé la twig de release y agregué algunas confirmaciones.

 D1 - D2 - D3 - R4 - R5 

Mientras tanto, se agregaron algunos compromisos para desarrollar

 D1 - D2 - D3 - D6 

Luego, git rebase -i HEAD~3 algunos commits de la twig de release usando git rebase -i HEAD~3 :

 D1 - x - x - R4 - R5 

¿Cómo se fusionará la release twig para develop usando git merge --no-ff release ? Quiero tenerlo así:

 D1 - D2 - D3 - R4 - R5 - D6 

¿Y existe la posibilidad de que me fusionen la twig con la eliminación de commits?

 D1 - x - x - R4 - R5 - D6 

Estoy esperando explicaciones sobre "detrás de la escena" 🙂

Si hiciste una revert en el release , revertiría esos commits en una fusión. Si hiciste una rebase no lo hará. Esto se debe a que revert muestra que los borras explícitamente y conservas ese hecho en el historial. rebase hace que parezca que esos commits nunca ocurrieron en el release , por lo que no hay motivo para que la merge elimine.

En cuanto a la prioridad, ambas twigs tienen la misma prioridad sin importar qué. Volviendo al último commit que las twigs tienen en común, si cada twig cambia algo de diferentes maneras, git lo mostrará como un conflicto de fusión. La única razón por la que la rebase no revierte esas confirmaciones es porque reescribió el historial para que parezca que nunca estuvo presente en la twig, para empezar.

Por otro lado, ¿te das count de que puedes probar estas cosas en git, ya sea en un clon o teniendo cuidado con tus twigs, en probablemente less time de lo necesario para hacer una pregunta?

Como una adición a las otras respuestas:

Me pregunto, ¿cuál es la prioridad de elegir compromisos durante la fusión en la situación?

Git normalmente no tiene la noción de "prioridad" durante las fusiones. Durante una combinación, todas las twigs son igualmente importantes, y Git intenta combinar los cambios de todas las twigs.

Si hay una contradicción (como diferentes twigs cambiando la misma línea de diferentes maneras), Git de alguna manera no permitirá que una twig "gane", sino que informará un conflicto de fusión.

Esta fue en realidad una decisión de layout deliberada. Linux hablando de fusionarse en Git:

Linus: Yo personalmente , quiero tener algo que sea muy repetible y no inteligente. Algo que entiendo o me dice que no puede hacerlo.

http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php

Entonces, deliberadamente, Git no intenta de alguna manera ingeniosamente determinar qué twig es "más importante", simplemente deja la decisión al usuario.

Parece que sabes git-rebase , así que:

 $ git checkout develop $ git rebase -i D1 release 

El modo interactivo le permite elegir y reorderar las confirmaciones de la manera que desee.