Hoe los ik een git merge-conflict op ten gunste van getrokken wijzigingen?

In principe moet ik alle conflicterende wijzigingen uit een werkende boomstructuur verwijderen zonder alle conflicten te moeten doorlopen met een git mergetoolterwijl ik alle conflictvrije wijzigingen behoud. Doe dit bij voorkeur tijdens het trekken, niet erna.

Antwoord 1, autoriteit 100%

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

Of, gewoon, voor de standaard repository:

git pull -X theirs

Als je al een conflictsituatie hebt…

git checkout --theirs path/to/file

Antwoord 2, autoriteit 67%

U kunt de recursieve “hun” strategie optiegebruiken:

git merge --strategy-option theirs

Van de man:

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.

Opmerking: zoals de man-pagina zegt, is de “ours” merge strategie-optieheel anders dan de “ours” merge strategie.

Antwoord 3, autoriteit 37%

Als je al een conflictsituatie hebt en je wilt gewoon allevan hen accepteren:

git checkout --theirs .
git add .

Als je het tegenovergestelde wilt doen:

git checkout --ours .
git add .

Dit is behoorlijk ingrijpend, dus zorg ervoor dat je echt alles op deze manier wilt wissen voordat je het doet.

Antwoord 4, autoriteit 14%

Ok, stel je het scenario voor waarin ik me net bevond:

Je probeert een merge, of misschien een cherry-pick, en je bent gestopt met

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

Je bekijkt nu het conflicterende bestand en je wilt je wijzigingen niet bewaren. In mijn geval hierboven was het bestand in conflict met alleen een nieuwe regel die mijn IDE automatisch had toegevoegd. Om uw wijzigingen ongedaan te maken en die van hen te accepteren, is de eenvoudigste manier:

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

Het omgekeerde hiervan (om de inkomende versie te overschrijven met uw versie) is

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

Verrassend genoeg kon ik dit antwoord niet zo gemakkelijk op internet vinden.

Antwoord 5, autoriteit 3%

Als je na git merge conflicten krijgt en je wilt of je of hun

git checkout --theirs .
git checkout --ours .

Antwoord 6, autoriteit 3%

De git pull -X theirsantwoorden kunnen een lelijke merge commit creëren, of een

geven

fout: uw lokale wijzigingen in de volgende bestanden worden overschreven door samenvoegen:

Als je lokale wijzigingen aan bestanden uit de repo gewoon wilt negeren, bijvoorbeeld op een client die altijd een mirror van een origin zou moeten zijn, voer je dit uit (vervang masterdoor de branch die je wilt ):

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

Hoe werkt het? git fetchdoet git pullmaar zonder merge. Dan git reset --hardzorgt ervoor dat je werkboom overeenkomt met de laatste commit. Al uw lokale wijzigingen aan bestanden in de repo worden weggegooid, maar nieuwe lokale bestanden blijven staan.

Antwoord 7

Om alle conflicten met de versie in een bepaalde branch op te lossen:

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

Dus, als u zich al in de samenvoegingsstatus bevindt en u de hoofdversie van de conflicterende bestanden wilt behouden:

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

Antwoord 8

Houd er rekening mee dat dit soms niet werkt:

git checkout –ours pad/naar/bestand

of

git checkout –hun pad/naar/bestand

Ik deed dit in plaats daarvan, ervan uitgaande dat HEAD van ons isen MERGE_HEAD van hen

git checkout HEAD -- path/to/file

of:

git checkout MERGE_HEAD -- path/to/file

Nadat we dit hebben gedaan en we zijn goed:

git add .

Als je meer wilt weten, bekijk dan hier de prachtige post van torek:
git checkout –ours verwijdert geen bestanden van lijst met niet-samengevoegde bestanden

Antwoord 9

VS-code (geïntegreerde Git) IDE-gebruikers:

Als u alle binnenkomende wijzigingen in het conflictbestandwilt accepteren, voert u de volgende stappen uit.

1. Go to command palette - Ctrl + Shift + P
2. Select the option - Merge Conflict: Accept All Incoming

Je kunt hetzelfde doen voor andere opties, zoals Alles accepteren, Alle huidige accepteren, enz.,

Antwoord 10

Als u zich al in een conflictsituatie bevindt en het pad niet één voor één wilt afrekenen. Je kunt proberen

git merge --abort
git pull -X theirs

Antwoord 11

Ik had een langlopende next-versionbranch met tonnen verwijderingen naar bestanden die waren gewijzigd op develop, bestanden die op verschillende plaatsen op beide branches waren toegevoegd , enz.

Ik wilde de volledige inhoud van de next-versionbranch naar developbrengen, alles in één geweldige merge commit.

De combinatie van de bovenstaande commando’s die voor mij werkte was:

git merge -X theirs next-version
# lots of files left that were modified on develop but deleted on next-version
git checkout next-version .
# files removed, now add the deletions to the commit
git add .
# still have files that were added on develop; in my case they are all in web/
git rm -r web

Geen nieuw antwoord, maar het combineren van bits uit vele antwoorden, deels om gerust te stellen dat je alvan deze antwoorden misschien nodig hebt.

Antwoord 12

git checkout --ours/theirslost niet uitsluitend conflicten op. Het checkt uit (neemt het hele bestand in beslag) van ours/theirs.

Stel dat we een bestand foohebben met wijzigingen in twee commits/branches/trees/whatever. Als er een conflict is geïntroduceerd door hen, evenals een wijziging, en we willen het conflict oplossen met behulp van ours— dan zal het gebruik van checkout --ours foode wijzigingen die conflicten introduceren, maar ook de wijzigingen.

SED gebruiken

Oplossen met behulp van hun:

sed -i -e '/<<<<<<</,/=======/d' -e '/>>>>>>>/d' foo

• -iPas het bestand aan,
• /<<<<<<</,/=======/dverwijder alles tussen en inclusief <<<<<<<en =======(onze)
• />>>>>>>/dverwijder de resterende conflictmarkering
• -especificeer meerdere patronen voor SED
• foohet bestand

Oplossen met de onze:

sed -i -e '/<<<<<<</d' -e '/=======/,/>>>>>>>/d' foo

Antwoord 13

van https://git-scm.com/ book/nl/v2/Git-Tools-Advanced-Merging

Hiermee wordt in feite een nep-samenvoeging uitgevoerd. Het zal een nieuwe merge commit opnemen
met beide takken als ouders, maar het zal niet eens naar de tak kijken
je bent aan het samenvoegen. Het zal gewoon opnemen als het resultaat van het samenvoegen
de exacte code in uw huidige vestiging.

$ git merge -s ours mundo

Samenvoeging gemaakt door de ‘onze’ strategie.

$ git diff HEAD HEAD~

Je kunt zien dat er geen verschil is tussen de vestiging waar we zaten
en het resultaat van de samenvoeging.

Dit kan vaak handig zijn om Git te laten denken dat a
branch is al samengevoegd als je later een merge doet. Zeg bijvoorbeeld:
je bent afgetakt van een release-branch en hebt daar wat werk aan gedaan
je zult op een gegeven moment terug willen mergen in je master branch. In
in de tussentijd moet er een bugfix op master worden gebackport naar je
tak vrijgeven. Je kunt de bugfix-branch samenvoegen met de release
branch en ook merge -s ours dezelfde branch in je master branch
(ook al is de oplossing er al) dus als je later de . samenvoegt
release branch opnieuw, er zijn geen conflicten van de bugfix.

Een situatie die ik nuttig heb gevonden als ik wil dat master de wijzigingen van een nieuwe onderwerpbranch weerspiegelt. Ik heb gemerkt dat -Xtheirs in sommige omstandigheden niet zonder conflicten samengaat…
bijv.

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

In dit geval was de oplossing die ik vond

$ git checkout topicFoo

van topicFoo, voeg eerst de master samen met behulp van de -s ours-strategie, dit zal de nep-commit creëren die alleen de status van topicFoo is.
$ git merge -s onze meester

controleer de gemaakte merge commit

$ git log

check nu de master branch

$ git checkout master

voeg de topic branch terug maar gebruik deze keer de -Xtheirs recursieve strategie, dit zal je nu een master branch presenteren met de status van topicFoo.

$ git merge -X theirs topicFoo