git - theirs - ¿Cómo puedo descartar cambios remotos y marcar un archivo como "resuelto"?

git pull conflict

Question

Tengo algunos archivos locales, los obtengo de una sucursal remota y hay conflictos. Sé que me gustaría mantener mis cambios locales e ignorar los cambios remotos que causan conflictos. ¿Existe un comando que pueda usar para decir "marcar todos los conflictos como resueltos, usar local"?

Answer 1

Asegúrate el origen del conflicto: si es el resultado de una git merge , mira la answer .

Pero si es el resultado de una base de datos de git rebase , para descartar cambios remotos (sus) y usar cambios locales , tendría que hacer una:

git checkout --theirs -- .

Consulte " Por qué se invierte el significado de" ours "y" theirs " para ver cómo se intercambian el ours y el theirs durante una rebase (porque se está revisando la rama upstream ).

Answer 2

git checkout tiene la opción --ours para verificar la versión del archivo que tenías localmente (en lugar de --theirs , que es la versión que --theirs ). Puedes pasar para completar el git checkout y decirle que revise todo en el árbol. Luego debe marcar los conflictos como resueltos, lo cual puede hacer con git add , y confirmar su trabajo una vez hecho:

git checkout --ours .  # checkout our local version of all files
git add -u             # mark all conflicted files as merged
git commit             # commit the merge

Tenga en cuenta el . en el comando de git checkout . Eso es muy importante y fácil de perder. git checkout tiene dos modos; una en la que se cambian las ramas, y otra en la que se comprueban los archivos fuera del índice en la copia de trabajo (a veces se los inserta en el índice de otra revisión primero). La forma en que se distingue es si ha pasado un nombre de archivo; si no ha pasado un nombre de archivo, intenta cambiar de rama (aunque si no pasa una rama tampoco, simplemente intentará verificar la rama actual nuevamente), pero se niega a hacerlo si hay archivos modificados eso eso afectaría. Por lo tanto, si desea un comportamiento que sobrescriba los archivos existentes, debe pasar . o un nombre de archivo para obtener el segundo comportamiento del git checkout .

También es una buena costumbre tener, al pasar un nombre de archivo, para compensarlo con -- , como git checkout --ours -- <filename> . Si no lo hace, y el nombre del archivo coincide con el nombre de una rama o etiqueta, Git pensará que desea verificar esa revisión, en lugar de verificar ese nombre de archivo, y así usar la primera forma de checkout mando.

Me extenderé un poco sobre cómo funcionan los conflictos y la merging en Git. Cuando se fusiona con el código de otra persona (que también ocurre durante una extracción, una extracción es esencialmente una búsqueda seguida de una combinación), hay pocas situaciones posibles.

Lo más simple es que estás en la misma revisión. En este caso, ya estás "actualizado" y no sucede nada.

Otra posibilidad es que su revisión sea simplemente una descendiente tuya, en cuyo caso tendrás una "fusión de avance rápido", en la que tu HEAD se actualizará para su confirmación, sin que se produzca una fusión (esto puede ser desactivado si realmente quieres grabar una fusión, usando --no-ff ).

Luego te metes en las situaciones en las que realmente necesitas unir dos revisiones. En este caso, hay dos resultados posibles. Una es que la fusión sucede limpiamente; todos los cambios están en diferentes archivos, o están en los mismos archivos, pero lo suficientemente separados que ambos conjuntos de cambios se pueden aplicar sin problemas. De forma predeterminada, cuando ocurre una fusión limpia, se confirma automáticamente, aunque puede deshabilitarla con --no-commit si necesita editarla de antemano (por ejemplo, si cambia el nombre de la función foo a la bar , y alguien más agrega un nuevo código que llama a foo , se fusionará limpiamente, pero producirá un árbol roto, por lo que es posible que desee limpiarlo como parte de la confirmación de fusión con el fin de evitar que se rompa el compromiso).

La última posibilidad es que haya una fusión real, y hay conflictos. En este caso, Git hará la mayor parte posible de la fusión y generará archivos con marcadores de conflicto ( <<<<<<< , ======= y >>>>>>> en su copia de trabajo. En el índice (también conocido como el "área de ensayo", el lugar donde los archivos son guardados por git add antes de confirmarlos), tendrá 3 versiones de cada archivo con conflictos; existe la versión original del archivo del antecesor de las dos ramas que está fusionando, la versión de HEAD (su lado de la fusión) y la versión de la rama remota.

Para resolver el conflicto, puede editar el archivo que está en su copia de trabajo, eliminar los marcadores de conflicto y corregir el código para que funcione. O bien, puede verificar la versión desde uno u otro lado de la fusión, usando git checkout --ours o git checkout --theirs . Una vez que ha puesto el archivo en el estado que desea, indica que ha terminado de fusionar el archivo y que está listo para comprometerse usando git add , y luego puede confirmar la fusión con git commit .