Pregunta Resolver los conflictos de fusión de Git a favor de sus cambios durante un tirón


¿Cómo resuelvo un conflicto de fusión de git a favor de los cambios extraídos?

Básicamente, necesito eliminar todos los cambios en conflicto de un árbol de trabajo sin tener que pasar por todos los conflictos con un git mergetool manteniendo todos los cambios libres de conflicto. Preferiblemente haciendo esto mientras tira, no después.


731
2018-05-22 07:18


origen


Respuestas:


Puedes usar la estrategia recursiva de "ellos" opción:

git merge --strategy-option theirs

Desde el hombre:

ours
    This option forces conflicting hunks to be auto-resolved cleanly by 
    favoring our version. Changes from the other tree that do not 
    conflict with our side are reflected to the merge result.

    This should not be confused with the ours merge strategy, which does 
    not even look at what the other tree contains at all. It discards 
    everything the other tree did, declaring our history contains all that
    happened in it.

theirs
    This is opposite of ours.

Nota: como dice la página del manual, la fusión "nuestra" opción de estrategia es muy diferente de la fusión "nuestra" estrategia.


576
2018-05-22 07:24



git pull -s recursive -X theirs <remoterepo or other repo>

O, simplemente, para el repositorio predeterminado:

git pull -X theirs

Si ya estás en un estado conflictivo ...

git checkout --theirs path/to/file

654
2018-02-14 11:06



Si ya estás en un estado conflictivo, y solo quieres aceptar todas de ellos:

git checkout --theirs .
git add .

Si quieres hacer lo opuesto:

git checkout --ours .
git add .

Esto es bastante drástico, así que asegúrese de que realmente quiere borrar todo así antes de hacerlo.


272
2017-11-06 15:18



Bien, imagínense el escenario en el que estaba yo:

Intentas un merge, o tal vez un cherry-pick, y estás detenido con

$ git cherry-pick 1023e24
error: could not apply 1023e24... [Commit Message]
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

Ahora, ve el archivo en conflicto y realmente no desea mantener sus cambios. En mi caso anterior, el archivo estaba en conflicto solo en una nueva línea que mi IDE había agregado automáticamente. Para deshacer los cambios y aceptar los de ellos, la forma más fácil es:

git checkout --theirs path/to/the/conflicted_file.php
git add path/to/the/conflicted_file.php

Lo opuesto a esto (sobrescribir la versión entrante con su versión) es

git checkout --ours path/to/the/conflicted_file.php
git add path/to/the/conflicted_file.php

Sorprendentemente, no pude encontrar esta respuesta muy fácilmente en la red.


200
2017-08-01 12:11



Para resolver todos los conflictos con la versión en una rama en particular:

git diff --name-only --diff-filter=U | xargs git checkout ${branchName}

Por lo tanto, si ya se encuentra en el estado de fusión, y desea conservar la versión maestra de los archivos en conflicto:

git diff --name-only --diff-filter=U | xargs git checkout master

15
2017-07-14 17:43



los git pull -X theirs las respuestas pueden crear un feo compromiso de fusión, o emitir un

error: los cambios locales en los siguientes archivos se sobrescribirán mediante la fusión:

Si simplemente desea ignorar cualquier modificación local de los archivos del repositorio, por ejemplo, en un cliente que siempre debe ser un reflejo de un origen, ejecute esto (reemplace master con la rama que desee):

git fetch && git reset --hard origin/master

¿Como funciona? git fetch hace git pull pero sin fusionar. Entonces git reset --hard hace que su árbol de trabajo coincida con el último compromiso. Todos sus cambios locales a los archivos en el repositorio serán descartado, pero los nuevos archivos locales se quedarán solos.


8
2018-01-23 11:00



Por favor no que a veces esto no trabajo:

git checkout --our path / to / file

o

git checkout --sur camino / a / archivo

Hice esto en cambio, asumiendo HEAD es nuestro y MERGE_HEAD es de ellos

git checkout HEAD -- path/to/file

o:

git checkout MERGE_HEAD -- path/to/file

Después de hacer esto y estamos bien:

git add .

Si quieres entender más, mira la maravillosa publicación de torek aquí: git checkout --ours no elimina archivos de la lista de archivos no fusionados


7
2018-04-27 08:47



de https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging

Esto básicamente hará una fusión falsa. Grabará un nuevo compromiso de fusión   con ambas ramas como padres, pero ni siquiera mirará la rama   te estás fusionando. Simplemente registrará como resultado de la fusión   el código exacto en tu rama actual.

$ git merge -s ours mundo

Fusión hecha por la estrategia 'nuestra'.

$ git diff HEAD HEAD~

Puedes ver que no hay diferencia entre la rama en la que estábamos   y el resultado de la fusión.

Esto a menudo puede ser útil para básicamente engañar a Git y hacerle pensar que   la rama ya está fusionada al hacer una fusión más adelante. Por ejemplo, di   usted se ramificó de una rama de lanzamiento y ha hecho algo de trabajo en él que   querrá volver a fusionarse con su rama principal en algún momento. En   Mientras tanto, es necesario que una corrección de errores en el maestro se transfiera a su   rama de lanzamiento. Puede fusionar la rama de corrección de errores en la versión   rama y también fusionar -s nuestra la misma rama en su rama principal   (a pesar de que la solución ya está allí), así que cuando más adelante   liberar rama nuevamente, no hay conflictos desde la corrección de errores.

Una situación que encontré útil si quiero que el maestro refleje los cambios de una nueva rama temática. Me di cuenta de que "Xtheirs no se fusiona sin conflictos en algunas circunstancias ... p.ej.

$ git merge -Xtheirs topicFoo 

CONFLICT (modify/delete): js/search.js deleted in HEAD and modified in topicFoo. Version topicFoo of js/search.js left in tree.

En este caso, la solución que encontré fue

$ git checkout topicFoo

de topicFoo, primero se fusiona en master usando la estrategia -s our, esto creará la confirmación falsa que es solo el estado de topicFoo. $ git merge -s nuestro maestro

verificar el compromiso de fusión creado

$ git log

ahora compra la rama maestra

$ git checkout master

fusionar la rama de tema nuevamente, pero esta vez use la estrategia recursiva -Xsir, esto ahora le presentará una rama principal con el estado de topicFoo.

$ git merge -X theirs topicFoo

0
2017-10-05 17:29