Question Résoudre les conflits de fusion Git en faveur de leurs changements lors d'une traction


Comment résoudre un conflit de fusion git en faveur de modifications tirées?

Fondamentalement, je dois supprimer tous les changements conflictuels d'un arbre de travail sans avoir à passer par tous les conflits avec un git mergetool tout en gardant tous les changements sans conflit. Préférablement faire cela en tirant, pas après.


731
2018-05-22 07:18


origine


Réponses:


Vous pouvez utiliser la stratégie "la leur" récursive option:

git merge --strategy-option theirs

Du homme:

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.

Note: comme le dit la page de manuel, le "nôtre" fusionne option de stratégie est très différent de la fusion "nôtre" stratégie.


576
2018-05-22 07:24



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

Ou, simplement, pour le référentiel par défaut:

git pull -X theirs

Si vous êtes déjà en conflit ...

git checkout --theirs path/to/file

654
2018-02-14 11:06



Si vous êtes déjà en conflit et que vous voulez simplement accepter tout de la leur:

git checkout --theirs .
git add .

Si vous voulez faire le contraire:

git checkout --ours .
git add .

C'est assez drastique, alors assurez-vous que vous voulez vraiment tout effacer comme ça avant de le faire.


272
2017-11-06 15:18



OK, imaginez le scénario dans lequel j'étais juste:

Vous essayez un mergeou peut-être un cherry-picket vous êtes arrêté avec

$ 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'

Maintenant, vous affichez le fichier en conflit et vous ne voulez vraiment pas conserver vos modifications. Dans mon cas ci-dessus, le fichier était en conflit sur une nouvelle ligne que mon IDE avait automatiquement ajouté. Pour annuler vos modifications et les accepter, le plus simple est:

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

L'inverse de ceci (pour remplacer la version entrante avec votre version) est

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

Étonnamment, je ne pouvais pas trouver cette réponse très facilement sur le Net.


200
2017-08-01 12:11



Pour résoudre tous les conflits avec la version dans une branche particulière:

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

Donc, si vous êtes déjà dans l'état de fusion et que vous souhaitez conserver la version principale des fichiers en conflit:

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

15
2017-07-14 17:43



le git pull -X theirs réponses peuvent créer un commit de fusion moche, ou émettre un

erreur: vos modifications locales aux fichiers suivants seront remplacées par fusion:

Si vous souhaitez simplement ignorer les modifications locales apportées aux fichiers du référentiel, par exemple sur un client qui doit toujours être le miroir d'une origine, exécutez master avec la branche que vous voulez):

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

Comment ça marche? git fetch Est-ce que git pull mais sans fusion. alors git reset --hard rend votre arbre de travail correspondant au dernier commit. Tous vos changements locaux aux fichiers dans le repo seront mis au rebut, mais de nouveaux fichiers locaux seront laissés seuls.


8
2018-01-23 11:00



S'il vous plaît pas que parfois cela va pas travailler:

git checkout --ours chemin / vers / fichier

ou

git checkout - leur chemin / vers / file

Je l'ai fait à la place, en supposant HEAD est le nôtre et MERGE_HEAD est le leur

git checkout HEAD -- path/to/file

ou:

git checkout MERGE_HEAD -- path/to/file

Après nous faisons cela et nous sommes bons:

git add .

Si vous voulez comprendre plus, voir le merveilleux post de torek ici: git checkout --ours ne supprime pas les fichiers de la liste des fichiers non fusionnés


7
2018-04-27 08:47



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

Cela va fondamentalement faire une fausse fusion. Il va enregistrer un nouveau commit de fusion   avec les deux branches en tant que parents, mais il ne regarde même pas la branche   vous fusionnez. Il enregistrera simplement comme le résultat de la fusion   le code exact dans votre branche actuelle.

$ git merge -s ours mundo

Fusion faite par la stratégie 'nôtre'.

$ git diff HEAD HEAD~

Vous pouvez voir qu'il n'y a pas de différence entre la branche sur laquelle nous étions   et le résultat de la fusion.

Cela peut souvent être utile pour faire croire à Git que   La branche est déjà fusionnée lors d'une fusion ultérieure. Par exemple, dites   vous avez dérivé une branche de libération et avez fait un peu de travail à ce sujet   vous voudrez fusionner dans votre branche principale à un moment donné. Dans   En attendant, un bug sur le maître doit être rétroporté dans votre   branche de libération. Vous pouvez fusionner la branche bugfix dans la version   branchez et fusionnez également - la nôtre est la même branche dans votre branche principale   (même si le correctif est déjà là) donc quand vous fusionnerez plus tard le   branchez à nouveau la branche, il n'y a pas de conflit avec le correctif.

Une situation que j'ai trouvée utile si je veux que le maître reflète les changements d'une nouvelle branche de sujet. J'ai remarqué que -Xtheirs ne fusionne pas sans conflits dans certaines circonstances ... par exemple.

$ 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.

Dans ce cas, la solution que j'ai trouvée était

$ git checkout topicFoo

à partir de topicFoo, fusionner d'abord dans master en utilisant la stratégie -son, cela va créer le faux commit qui est juste l'état de topicFoo. $ git merge -s notre maître

vérifier le commit de fusion créé

$ git log

maintenant vérifier la branche principale

$ git checkout master

fusionner la branche de sujet en arrière mais cette fois-ci utiliser la stratégie récursive -Xtheirs, ceci vous présentera maintenant une branche master avec l'état de topicFoo.

$ git merge -X theirs topicFoo

0
2017-10-05 17:29