Rozwiązywanie konfliktów Git merge na rzecz ich zmian podczas pull

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

Lub po prostu dla domyślnego repozytorium:

git pull -X theirs

Jeśli jesteś już w stanie konfliktu...

git checkout --theirs path/to/file

Jeśli jesteś już w stanie konfliktu i chcesz zaakceptować wszystkie z nich:

git checkout --theirs .
git add .

Jeśli chcesz zrobić odwrotnie:

git checkout --ours .
git add .

Ok, wyobraź sobie scenariusz, w którym właśnie byłem:

Próbujesz merge, a może cherry-pick, i jesteś zatrzymany przez

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

Teraz przeglądasz skonfliktowany plik i naprawdę nie chcesz zachować swoich zmian. W moim przypadku powyżej, plik był skonfliktowany NA tylko nowej linii mój IDE miał automatycznie dodane. Aby cofnąć zmiany i zaakceptować ich, najprostszym sposobem jest:

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

Konwersja tego (aby nadpisać nadchodzącą wersję z twoją wersją) To

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

Zaskakująco, I nie mogłem znaleźć tej odpowiedzi bardzo łatwo w sieci.

Aby rozwiązać wszystkie konflikty z wersją w danej gałęzi:

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

Tak więc, jeśli jesteś już w stanie scalania i chcesz zachować wersję główną konfliktujących plików:

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

Odpowiedzi git pull -X theirs mogą utworzyć brzydki commit scalający lub wydać

Błąd: Twoje lokalne zmiany w następujących plikach zostaną nadpisane przez scalenie:

Jeśli chcesz po prostu zignorować lokalne modyfikacje plików z repo, na przykład na kliencie, który zawsze powinien być serwerem lustrzanym pochodzenia, uruchom to (zastąp master z wybraną gałęzią):

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

Proszę nie żeby czasem to nie działało : {]}

Git checkout --ours path/to / file

git checkout HEAD -- path/to/file

git checkout MERGE_HEAD -- path/to/file

git add .

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

To w zasadzie zrobi fałszywe połączenie. Zarejestruje nowy commit scalający z obydwoma gałęziami jako rodzicami, ale nawet nie spojrzy na gałąź łączysz się. Będzie po prostu nagrywać w wyniku połączenia dokładny kod w bieżącej gałęzi.

$ git merge -s ours mundo

Merge made by the' ours ' strategy.

$ git diff HEAD HEAD~

Widać, że nie ma różnicy między branch we were on i wynik połączenia.

To często może być przydatne, aby w zasadzie oszukać Gita, myśląc, że branch jest już scalany podczas późniejszego scalania. Na przykład, powiedzmy rozgałęziłeś gałąź release i wykonałeś nad nią trochę pracy, która w pewnym momencie będziesz chciał ponownie połączyć się ze swoją gałęzią master. W w międzyczasie jakaś poprawka na master musi zostać ponownie zaimportowana do twojego uwolnij gałąź. Możesz scalić gałąź bugfix do wydania oddział a także połącz-s naszą tę samą gałąź z Twoją główną gałąź (mimo, że poprawka już tam jest), więc kiedy później połączysz ponownie wydaj gałąź, nie ma konfliktów z poprawką.

Sytuacja, którą uznałem za przydatną, jeśli chcę, aby master odzwierciedlał zmiany nowej gałęzi tematycznej. Zauważyłem ,że-Xtheirs nie łączy się bez konfliktów w pewnych okolicznościach... np.

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

W tym przypadku znalazłem rozwiązanie

$ git checkout topicFoo

From topicFoo, najpierw połącz w master używając strategii-s ours, stworzy to fałszywy commit, który jest tylko stanem topicFoo. $ git merge-s ours master

Sprawdź utworzony commit merge

$ git log

Teraz sprawdź gałąź master

$ git checkout master

Połącz gałąź topic z powrotem, ale tym razem użyj rekurencyjnej strategii-Xtheirs, to teraz przedstawi Ci gałąź master ze stanem topicFoo.

$ git merge -X theirs topicFoo