diferencia entre git merge nuestros sus commands

Estoy practicando GIT. ¿Cuál es la diferencia entre los commands a continuación?

git merge -s ours branch git merge -s theirs branch git merge -X ours branch git merge -X theirs branch 

Antes de comenzar esta respuesta, permítanme enfatizar que hay dos palabras diferentes que se escriben "fusionar". Hay una forma de verbo para fusionar , que significa "combinar cambios". Hay un nombre o una forma de adjetivo, una combinación o una fusión de compromiso , que se refiere a un tipo específico de compromiso.

El command git merge por lo general hace ambas cosas: fusiona (verbo) algunos cambios, y luego realiza una combinación (sustantivo) o una combinación de compromiso (adjetivo). Sin embargo, Git tiene muchas forms de hacer la forma verbal de fusión. También permite que el command git merge omita la fusión de forma nominal final (pero ignoraremos este caso por completo aquí).

Estrategia u opción extendida: la versión corta

La versión corta es que casi nunca quieres la opción de estrategia , la -s ours .

Usando las opciones -X (eXtended), puede decirle a Git que favorezca el lado "nuestro" o "suyos" de una combinación en el caso de un conflicto . Es decir, supongamos que la versión base de fusión del file wallaby.txt dice, en parte:

 The Bennett's wallaby is a variety of the networking-necked wallaby. 

Una de las dos versiones de puntas de bifurcación, llamémosla lado izquierdo o local o --ours versión, dice:

 The Bennett's wallaby is a smaller variety of the networking-necked wallaby. 

La otra versión de punta de ramificación, es decir, el lado derecho o remoto u otro o --theirs dice:

 The Bennett's wallaby, which is found on Tasmania, is a variety of the networking-necked wallaby. 

Cuando comparamos la versión base con las dos sugerencias de twigs, las comparaciones hacen cambios similares, pero no exactamente iguales, en el mismo range de líneas:

 $ git diff $base $left ... The Bennett's wallaby is -a variety of the networking-necked wallaby. +a smaller variety of the networking-necked wallaby. ... 

Pero:

 $ git diff $base $right ... -The Bennett's wallaby is -a variety of the networking-necked wallaby. +The Bennett's wallaby, +which is found on Tasmania, +is a variety of the networking-necked wallaby. 

Estos dos cambios chocan, y obtendrás un conflicto de fusión .

La opción eXtended -X ours our significa "preferir nuestro cambio": donde chocan los dos cambios, ignore por completo su cambio y tome el nuestro en su lugar. La opción eXtended -X theirs significa "preferir su cambio", es decir, ignorar la nuestra.

Tenga en count que cualquiera que sea el cambio que prefiera, perderá algo aquí. Un cambio menciona que el wallaby de Bennett es un poco más pequeño, y el otro menciona que es la forma de Tasmania. Si eliges solo uno, pierdes el otro. Probablemente deberías combinar este cambio manualmente, en lugar de dejar que Git elija un lado.

Cuándo y por qué podría usar -s ours

Si este es el único cambio en el file, usar -s ours lugar de -X ours no haría una diferencia en esta combinación particular de nivel de file: de cualquier manera tomaríamos "our" (left-side) change, e ignoraríamos el suyo . Pero supongamos además que solo su versión corrige un error tipográfico en otro lugar del file:

  $ git diff $base $right ... -walaby +wallaby ... 

sin nada como eso en la $left (local or --ours ). Si usamos -X ours lugar de -s ours , al less recogeremos esta solución. Por supuesto, el lado derecho podría tener un cambio que agregue errores tipocharts en lugar de eliminarlos. Git no lo sabrá ni le importará: su trabajo es combinar los cambios, no decidir si tienen sentido, ya sea individualmente o combinados.

Además, como mencionó Tim Beigeleisen en un comentario anterior , la opción -s ours ni siquiera mira a la diferencia del lado derecho. De hecho, ¡no corre ninguna dificultad en absoluto! Le dice a Git que realice la fusión sin utilizar el otro lado de ninguna manera. En otras palabras, simplemente registra que hubo una fusión, sin realmente fusionarse.

La única razón para hacer esto es hacer un logging de historial de compromiso de la fusión. Es esta historia, como se registra en el gráfico de compromiso en sí, lo que determina cómo usted y Git "verán" lo que sucedió, cuando usted, o cualquier otra persona, vuelva a mirar más tarde. La presencia de un compromiso de fusión significa que usted y Git verán la fusión como si ya hubieran tomado todas las partes buenas de lo que se fusionó, incluso si el método de "tomar" era ignorar todo. Habiendo tomado todas esas partes, nunca las volverás a tomar: así que la -s ours te permite "matar" una twig, no simplemente ignorándola, sino registrando toda la historia que deliberadamente la mataste.

Git solo registra el resultado, no el método

Git no registra la estrategia de combinación ni ninguna opción de estrategia. Entonces, la única manera de saber si alguien usó tales opciones es adivinar. Si encuentra algún repository con algunos commit de fusión dentro de él, puede repetir las fusiones y ver si obtiene el mismo resultado. Si obtienes el mismo resultado, quizás la persona que realizó la fusión usó exactamente el mismo command que acabas de usar. Si obtienes un resultado diferente , quizás la persona que realizó la fusión usó un command diferente o un set diferente de arguments. ¡O quizás resolvieron cualquier conflicto manualmente!

Más antecedentes

Para get más información, permítanme citar de mi libro perennemente-no-haciendo-mucho-progresar (porque tengo un trabajo :-)).


Una visión de alto nivel de la fusión

El objective de una fusión es fácil de entender. Varias personas o grupos, o incluso una sola persona con dos o más tareas, comenzaron desde una base de código común e hicieron una serie de cambios. Por ejemplo, en Marsupial Maker, Alice puede estar trabajando en wombats mientras Bob trabaja en canguros. Cada persona o grupo (o incluso una sola persona que asume múltiples roles) trabaja en su repository privado y / o sucursal privada. Estas dos líneas de desarrollo, es decir, twigs en el sentido filosófico que señalamos en el Capítulo 1, están relacionadas por este punto de partida común. No nos preocuparemos aún de cómo se las arreglan para compartir sus compromisos, pero en algún momento, alguien-tal vez Alice o Bob, o tal vez una tercera persona-combinará los cambios. La combinación debería tomar todas las partes buenas de ambos cambios. El método más simple de combinar es realizar la combinación de tres vías del mismo capítulo. Ahora que comprendemos los charts de compromiso y tenemos una idea general sobre cómo comparar los compromisos más nuevos con los anteriores, es hora de echar un breve vistazo de alto nivel a cómo se fusionan Git y Mercurial.

Dos commits y una base de combinación

En el Capítulo 2, observamos brevemente (ver página 38 y página 45) que el LCA de dos compromisos es su base de fusión . En algunos casos, puede haber más de una base de combinación, pero esto es raro y aún no lo abordaremos. En su lugar, observemos que, presumiblemente, la base de fusión única es, por definición, no solo un antecesor común de otras dos confirmaciones. De hecho, es el punto de partida común correcto : es el primer compromiso que se puede alcanzar desde las dos cabezas (Mercurial) o las puntas de las twigs (Git) que estamos fusionando. El VCS necesita encontrar la base de fusión para descubrir tanto lo que hicimos como lo que hicieron.

Tanto en Git como en Mercurial, elegimos uno de nuestros dos commits por el process normal de pago. Cualquier compromiso que hayamos revisado ahora, nuestro commit actual participa en la fusión. Elegimos un segundo compromiso utilizando algún identificador de compromiso apropiado, generalmente un nombre de sucursal pero ocasionalmente un ID de hash, o en Mercurial, un número de revisión simple (o a veces nada en absoluto, y el VCS lo calcula para nosotros). Ese será el compromiso "otro" o "suyo". 18 Entonces podemos simplemente ejecutar git merge otherbranch o hg merge otherbranch .


18 Llamo a los tres commits base , actual y otro aquí. Git no tiene un nombre único y consistente para las confirmaciones actuales y otras. Mercurial consistentemente los llama los locales y otros compromisos. También me refiero a los dos compromisos no básicos como los lados de la fusión. En varios lugares, Git llama al commit actual y al otro comete el suyo . Sin embargo, hay un problema con la nomenclatura de nosotros / ellos que veremos más adelante, cuando cubramos la elección y el cambio de date.