- 1 - Utilización de -suyo/suyas en una fusión
- 2 - Utilización de -suyo/suyas en un cambio de base
- 3 - Conclusión
Si ha llegado a esta página, es probable que se encuentre en medio de un conflicto de fusión en estos momentos. Para solucionar los conflictos, a menudo tenemos que abrir el archivo y resolver manualmente cada uno de los conflictos, pero a veces tenemos suerte y podemos mantener una versión y desechar la otra por completo. Para ello, podemos utilizar git checkout
con una de las dos banderas: --ours
o --su
.
Conveniente, ¿verdad? Puede que no.
El uso de --ours
y --su
puede ser un poco confuso al principio, así que vamos a sumergirnos y aprender con el ejemplo.
resumiendo
Con función
rama comprobada.
git merge master | git rebase master | |
---|---|---|
Mantener los cambios de maestro | --su | --ours |
Mantener los cambios de función | --ours | --su |
Siga leyendo para obtener una explicación.
1 - Utilización de -suyo/suyas en una fusión
Técnicamente hablando, el uso de git checkout --ours/--theirs
sólo es aplicable durante una fusión. Es posible que se pregunte acerca de rebases, y voy a explicar que en el siguiente paso.
Para simplificar, empecemos con un conflicto de fusión básico. Imagina que nuestro historial git tiene este aspecto:
A---B---C característica / D---E---F---G maestro
Las letras significan un commit, y cada commit incluye cambios en nuestro archivo: myscript.py.
Así que se introdujeron cambios en myscript.py
en ambos maestro
y función
Una estrategia habitual consiste en fusionar los cambios de la rama maestra con la rama de características durante el desarrollo para evitar que la rama de características se quede demasiado obsoleta. Pero cuando vamos a fusionar maestro
en función
vamos a tener problemas:
(característica) $ git merge master Fusión automática de myscript.py CONFLICTO (contenido): Conflicto de fusión en myscript.py La fusión automática falló; arregle los conflictos y luego confirme el resultado.
En la mayoría de los casos, querrá abrir myscript.py
y resolver los conflictos de fusión. Pero en algunos casos, querrá ignorar completamente una versión y mantener la otra. Aquí es donde git checkout --ours/--theirs
entra en juego.
Utilice --ours
mantener la versión en la rama actual
Puesto que tenemos nuestro función
podemos utilizar --ours
para mantener la versión de myscript.py
que reside en el función
e ignorar la versión de maestro
.
git checkout --ours myscript.py
Utilice --su
para mantener la versión de la rama que se fusiona en
Y --su
consigue lo contrario. Si queremos descartar la versión de myscript.py
que reside en nuestra rama actual y mantener la versión de maestro
podemos utilizar --su
.
git checkout --theirs myscript.py
2 - Utilización de -suyo/suyas en un cambio de base
Cuando nos encontramos con conflictos de fusión durante un rebase, estamos efectivamente en medio de una fusión, por lo que las reglas para git checkout --ours/--theirs
Sin embargo, la parte complicada es identificar la rama "actual". Permítanme explicar lo que sucede durante un rebase.
¿Qué ocurre durante un rebase?
De nuevo, supongamos la siguiente historia:
A---B---C característica / D---E---F---G maestro
Cuando volvamos a basar maestro
"en" función
...lo que realmente estamos haciendo es esto:
"Retroceder" al ancestro común y guardar la diferencia
En nuestro caso, retrocedemos hasta la confirmación E y guardar el diff de cada commit introducido por el comando función
rama.
A---B---C (guardado en archivos temporales) función / D---E---F---G maestro
Restablecer el función
rama a la confirmación actual desde maestro
En función
tiene ahora la misma historia que maestro
.
A---B---C (guardado en archivos temporales) función / D---E---F---G maestro
Aplique los cambios guardados de la función
rama
Ahora cada cambio del función
rama ( A
, B
y C
) se aplicará al nuevo función
Es importante señalar, por el bien de esta guía, que esto se logra a través de una fusión.
La nueva historia tiene este aspecto:
A---B---C característica / D---E---F---G maestro
Bien, ¿cómo puedo utilizar git checkout --ours/--theirs
durante un rebase?
El objetivo de esta larga explicación era mostrar que cuando se solucionan conflictos de fusión en medio de un rebase, la rama "actual" ya no es la original. función
sino una nueva rama actualizada con maestro
Y los commits que se están fusionando en la rama actual son los commits de tu rama original. Así que --ours
y --su
aparecerá invertida.
Utilice --ours
para mantener los cambios de la rama a la que se está rebasando ( maestro
)
Al principio de la nueva base de datos, teníamos función
rama comprobada, por lo que puede parecer retrógrado, pero vamos a utilizar --ours
para mantener los cambios del maestro.
git checkout --ours myscript.py
Utilice --su
para conservar los cambios de la rama "actual" ( función
)
Y, naturalmente, lo contrario. Utilizar --su
para mantener los cambios del función
rama.
git checkout --theirs myscript.py
3 - Conclusión
Sé que esto puede resultar confuso, así que te ruego que me digas en los comentarios si esta guía te ha resultado útil o si necesitas más aclaraciones.