Hoe u samenvoegconflicten in een Git-repository oplost

Ik wil samenvoegconflicten in mijn Git-repository oplossen.

Hoe kan ik dat doen?


Antwoord 1, autoriteit 100%

Probeer: git mergetool

Het opent een GUI die u door elk conflict leidt, en u kunt kiezen hoe u wilt samenvoegen. Soms is er achteraf wat handbewerking voor nodig, maar meestal is het op zich al voldoende. Het is veel beter dan alles met de hand te doen.

Volgens Josh Glover’s opmerking:

Het commando

opent niet noodzakelijk een GUI, tenzij u er een installeert. Het uitvoeren van git mergetool voor mij resulteerde in het gebruik van vimdiff. U kunt installeren
een van de volgende tools om het in plaats daarvan te gebruiken: meld, opendiff,
kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse,
ecmerge, p4merge, araxis, vimdiff, emerge.

Hieronder staat de voorbeeldprocedure om vimdiff te gebruiken voor het oplossen van samenvoegconflicten. Gebaseerd op deze link

Stap 1: Voer de volgende opdrachten uit in uw terminal

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

Hiermee wordt vimdiff ingesteld als de standaard samenvoegtool.

Stap 2: Voer de volgende opdracht uit in terminal

git mergetool

Stap 3: u ziet een vimdiff-weergave in het volgende formaat

  г=======T======T========¬
  ¦       ¦      ¦        ¦
  ¦ LOCAL ¦ BASE ¦ REMOTE ¦
  ¦       ¦      ¦        ¦
  ¦=======¦======¦========¦
  ¦                       ¦
  ¦        MERGED         ¦
  ¦                       ¦
  L=======================-

Deze 4 weergaven zijn

LOKAAL dit is een bestand van de huidige tak

BASE gemeenschappelijke voorouder, hoe het bestand eruitzag voor beide wijzigingen

REMOTE bestand dat u in uw branch samenvoegt

MERGED resultaat samenvoegen, dit wordt opgeslagen in de repo

Je kunt tussen deze weergaven navigeren met ctrl+w. U kunt de SAMENGEVOEGDE weergave direct bereiken met ctrl+w gevolgd door j.

Meer informatie over vimdiff-navigatie vindt u hier en hier.

Stap 4. U kunt de SAMENGEVOEGDE weergave op de volgende manier bewerken

Als u wijzigingen wilt ontvangen van REMOTE

:diffg RE

Als je wijzigingen wilt ontvangen van BASE

:diffg BA

Als u wijzigingen van LOKAAL wilt ontvangen

:diffg LO

Stap 5. Opslaan, afsluiten, vastleggen en opruimen

:wqa opslaan en afsluiten van vi

git commit -m "message"

git clean Verwijder extra bestanden (bijv. *.orig) gemaakt door diff tool.


Antwoord 2, autoriteit 55%

Hier is een waarschijnlijk gebruiksscenario, van bovenaf:

Je gaat wat wijzigingen doorvoeren, maar oeps, je bent niet up-to-date:

git fetch origin
git pull origin master
From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

Dus je bent up-to-date en probeert het opnieuw, maar je hebt een conflict:

git add filename.c
git commit -m "made some wild and crazy changes"
git pull origin master
From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.

Dus u besluit de wijzigingen te bekijken:

git mergetool

Oh my, oh my, stroomopwaarts heeft een aantal dingen veranderd, maar om mijn wijzigingen te gebruiken… nee… hun wijzigingen…

git checkout --ours filename.c
git checkout --theirs filename.c
git add filename.c
git commit -m "using theirs"

En dan proberen we het nog een laatste keer

git pull origin master
From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

Ta-da!


Antwoord 3, autoriteit 24%

Ik merk dat samenvoeghulpmiddelen me zelden helpen het conflict of de oplossing te begrijpen. Ik heb meestal meer succes door naar de conflictmarkeringen in een teksteditor te kijken en git log als aanvulling te gebruiken.

Hier zijn een paar tips:

Tip één

Het beste wat ik heb gevonden is om de samenvoegconflictstijl “diff3” te gebruiken:

git config merge.conflictstyle diff3

Dit levert conflictmarkeringen op zoals deze:

<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.
>>>>>>>

Het middelste gedeelte is hoe de gemeenschappelijke voorouder eruit zag. Dit is handig omdat je het kunt vergelijken met de bovenste en onderste versies om een ​​beter beeld te krijgen van wat er op elke vertakking is gewijzigd, waardoor je een beter idee krijgt van wat het doel van elke wijziging was.

Als het conflict maar een paar regels is, maakt dit het conflict over het algemeen heel duidelijk. (Weten hoe je een conflict oplost is heel anders; je moet je bewust zijn van waar andere mensen mee bezig zijn. Als je in de war bent, is het waarschijnlijk het beste om die persoon gewoon in je kamer te roepen, zodat ze kunnen zien wat je zoekt op.)

Als het conflict langer duurt, knip en plak ik elk van de drie secties in drie afzonderlijke bestanden, zoals “mijn”, “algemeen” en “hun”.

Dan kan ik de volgende commando’s uitvoeren om de twee diff-hunks te zien die het conflict hebben veroorzaakt:

diff common mine
diff common theirs

Dit is niet hetzelfde als het gebruik van een merge-tool, aangezien een merge-tool ook alle niet-conflicterende diff-hunks zal bevatten. Ik vind dat storend.

Tip twee

Iemand heeft dit al genoemd, maar het begrijpen van de bedoeling achter elke diff-hunk is over het algemeen erg nuttig om te begrijpen waar een conflict vandaan komt en hoe ermee om te gaan.

git log --merge -p <name of file>

Dit toont alle commits die dat bestand hebben geraakt tussen de gemeenschappelijke voorouder en de twee heads die je aan het samenvoegen bent. (Dus het bevat geen commits die al in beide branches bestaan ​​voordat ze worden samengevoegd.) Dit helpt je om diff-hunks te negeren die duidelijk geen factor zijn in je huidige conflict.

Tip drie

Verifieer uw wijzigingen met geautomatiseerde tools.

Als je geautomatiseerde tests hebt, voer die dan uit. Als je een lint hebt, voer dat dan uit. Als het een bouwbaar project is, bouw het dan voordat je het vastlegt, enz. In alle gevallen moet je een beetje testen om er zeker van te zijn dat je wijzigingen niets verbreken. (Ok, zelfs een samenvoeging zonder conflicten kan de werkende code breken.)

Tip vier

Plan vooruit; communiceren met collega’s.

Vooruit plannen en weten waar anderen mee bezig zijn, kan helpen om samenvoegconflicten te voorkomen en/of eerder op te lossen, terwijl de details nog vers in het geheugen liggen.

Als u bijvoorbeeld weet dat u en iemand anders allebei aan verschillende refactoring werken die beide van invloed zijn op dezelfde set bestanden, moet u van tevoren met elkaar praten om een ​​beter idee te krijgen van welke typen wijzigingen elk van je maakt. U kunt veel tijd en moeite besparen als u uw geplande wijzigingen serieel in plaats van parallel uitvoert.

Voor grote refactorings die een grote hoeveelheid code doorkruisen, moet u sterk overwegen om serieel te werken: iedereen stopt met werken aan dat deel van de code terwijl één persoon de volledige refactoring uitvoert.

Als je niet serieel kunt werken (misschien door tijdsdruk), dan helpt het communiceren over verwachte samenvoegconflicten je in ieder geval om de problemen eerder op te lossen terwijl de details nog vers in het geheugen liggen. Als een collega bijvoorbeeld een storende reeks commits maakt in de loop van een periode van een week, kun je ervoor kiezen om gedurende die week een of twee keer per dag samen te voegen/rebaseren op die collega-branch. Op die manier kun je, als je samenvoeg-/rebase-conflicten vindt, deze sneller oplossen dan wanneer je een paar weken wacht om alles samen te voegen tot één grote klont.

Tip vijf

Als je niet zeker bent van een samenvoeging, forceer het dan niet.

Samenvoegen kan overweldigend zijn, vooral wanneer er veel conflicterende bestanden zijn en de conflictmarkeringen honderden regels beslaan. Vaak nemen we bij het schatten van softwareprojecten niet genoeg tijd voor overhead-items zoals het afhandelen van een lastige samenvoeging, dus het voelt als een echte belemmering om meerdere uren te besteden aan het ontleden van elk conflict.

Op de lange termijn zijn vooruit plannen en bewust zijn van waar anderen mee bezig zijn de beste hulpmiddelen om te anticiperen op samenvoegconflicten en jezelf voor te bereiden om ze in minder tijd correct op te lossen.


Antwoord 4, autoriteit 11%

  1. Identificeer welke bestanden in conflict zijn (Git zou je dit moeten vertellen).

  2. Open elk bestand en onderzoek de verschillen; Git bakent ze af. Hopelijk is het duidelijk welke versie van elk blok je moet behouden. Mogelijk moet u dit bespreken met collega-ontwikkelaars die de code hebben gemaakt.

  3. Zodra je het conflict in een bestand hebt opgelost git add the_file.

  4. Zodra je alle conflicten hebt opgelost, voer je git rebase --continue of welk commando dan ook uit
    Git zei te doen als je klaar was.


Antwoord 5, autoriteit 4%

Samenvoegconflicten treden op wanneer er tegelijkertijd wijzigingen in een bestand worden aangebracht. Hier is hoe het op te lossen.

git CLI

Hier zijn eenvoudige stappen wat u moet doen als u in een conflictsituatie komt:

  1. Let op de lijst met conflicterende bestanden met: git status (onder de sectie Unmerged paths).
  2. Los de conflicten afzonderlijk voor elk bestand op een van de volgende manieren op:

    • Gebruik GUI om de conflicten op te lossen: git mergetool (de gemakkelijkste manier).

    • Om de externe/andere versie te accepteren, gebruik: git checkout --theirs path/file. Hiermee worden alle lokale wijzigingen die je voor dat bestand hebt gedaan, afgewezen.

    • Om de lokale/onze versie te accepteren, gebruik: git checkout --ours path/file

      U moet echter voorzichtig zijn, aangezien op afstand wijzigingen zijn aangebracht in de conflicten die om de een of andere reden zijn gedaan.

      Gerelateerd: Wat is de precieze betekenis van “ons” en “hun” in git?

    • Bewerk de conflicterende bestanden handmatig en zoek naar het codeblok tussen <<<<</>>>>> kies dan de versie van boven of onder =====. Zie: Hoe conflicten worden gepresenteerd.

    • Pat- en bestandsnaamconflicten kunnen worden opgelost door git add/git rm.

  3. Bekijk ten slotte de bestanden die klaar zijn om vast te leggen met: git status.

    Als je nog steeds bestanden hebt onder Unmerged paths, en je hebt het conflict handmatig opgelost, laat Git dan weten dat je het hebt opgelost door: git add path/file .

  4. Als alle conflicten met succes zijn opgelost, bevestig de wijzigingen dan door: git commit -a en push zoals gewoonlijk naar remote.

Zie ook: Een samenvoegconflict oplossen vanaf de opdrachtregel op GitHub

Voor praktische tutorial, check: Scenario 5 – Samenvoegconflicten oplossen door Katacoda.

DiffMerge

Ik heb met succes DiffMerge gebruikt, waarmee bestanden visueel kunnen worden vergeleken en samengevoegd op Windows, macOS en Linux/Unix .

Het kan grafisch de wijzigingen tussen 3 bestanden weergeven en het maakt automatisch samenvoegen mogelijk (indien veilig) en volledige controle over het bewerken van het resulterende bestand.

DiffMerge

Bron afbeelding: DiffMerge (Linux-screenshot)

Download het eenvoudig en voer het uit in repo als:

git mergetool -t diffmerge .

macOS

Op macOS kun je installeren via:

brew install caskroom/cask/brew-cask
brew cask install diffmerge

En waarschijnlijk (indien niet opgegeven) heb je de volgende extra eenvoudige wrapper nodig die in je PATH wordt geplaatst (bijv. /usr/bin):

#!/bin/sh
DIFFMERGE_PATH=/Applications/DiffMerge.app
DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge
exec ${DIFFMERGE_EXE} --nosplash "$@"

Dan kunt u de volgende sneltoetsen gebruiken:

  • ?AltOmhoog/Omlaag om naar vorige/volgende wijzigingen te gaan.
  • ?AltLinks/Rechts om wijziging van links of rechts te accepteren

Als alternatief kunt u opendiff (onderdeel van Xcode Tools) waarmee je twee bestanden of mappen kunt samenvoegen om een ​​derde bestand of map te maken.


Antwoord 6, autoriteit 4%

Bekijk de antwoorden in Stack Overflow-vraag Een samenvoeging in Git afbreken, vooral Charles Bailey’s antwoord dat laat zien hoe je de verschillende versies van het bestand met problemen, bijvoorbeeld

# Common base version of the file.
git show :1:some_file.cpp
# 'Ours' version of the file.
git show :2:some_file.cpp
# 'Theirs' version of the file.
git show :3:some_file.cpp

Antwoord 7, autoriteit 3%

Als je vaak kleine commits maakt, begin dan met het bekijken van de commit opmerkingen met git log --merge. Dan zal git diff je de conflicten tonen.

Voor conflicten die meer dan een paar regels omvatten, is het gemakkelijker om te zien wat er aan de hand is in een externe GUI-tool. Ik hou van opendiff — Git ondersteunt ook vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, komen uit de doos en je kunt anderen installeren: git config merge.tool "your.tool" zal instellen je gekozen tool en dan git mergetool na een mislukte samenvoeging zal je de diffs in context laten zien.

Elke keer dat je een bestand bewerkt om een ​​conflict op te lossen, zal git add filename de index updaten en je diff zal het niet langer tonen. Wanneer alle conflicten zijn afgehandeld en hun bestanden zijn git add-ed, zal git commit je samenvoeging voltooien.


Antwoord 8, autoriteit 2%

Ik wil mijn of hun volledige versie, of ik wil individuele wijzigingen bekijken en voor elk ervan beslissen.

Accepteer mijn of hun versie volledig:

Accepteer mijn versie (lokaal, de onze):

git checkout --ours -- <filename>
git add <filename>              # Marks conflict as resolved
git commit -m "merged bla bla"  # An "empty" commit

Accepteer hun versie (afstandsbediening, die van hen):

git checkout --theirs -- <filename>
git add <filename>
git commit -m "merged bla bla"

Als u voor alle conflictbestanden wilt doen:

git merge --strategy-option ours

of

git merge --strategy-option theirs

Bekijk alle wijzigingen en accepteer ze afzonderlijk

  1. git mergetool
  2. Bekijk wijzigingen en accepteer een van beide versies voor elk ervan.
  3. git add <filename>
  4. git commit -m "merged bla bla"

Standaard mergetool werkt in opdrachtregel. Het gebruik van een samenvoegtool voor de opdrachtregel zou een aparte vraag moeten zijn.

U kunt hiervoor ook visuele tool installeren, b.v. meld en voer uit

git mergetool -t meld

Het opent de lokale versie (de onze), de “basis” of “samengevoegde” versie (het huidige resultaat van de samenvoeging) en de externe versie (de hunne). Sla de samengevoegde versie op als je klaar bent, voer git mergetool -t meld opnieuw uit totdat je “Geen bestanden hoeft samen te voegen”, ga dan naar Stappen 3. en 4.


Antwoord 9, autoriteit 2%

Zie Hoe conflicten worden gepresenteerd of, in Git, de git merge documentatie om te begrijpen wat merge conflict markers zijn.

Ook de Hoe conflicten op te lossen sectie legt uit hoe de conflicten op te lossen:

Nadat je een conflict hebt gezien, kun je twee dingen doen:

  • Beslis niet samen te voegen. De enige opschoning die je nodig hebt is om het indexbestand te resetten naar de HEAD-commit naar reverse 2. en om de werkboomveranderingen op te ruimen die zijn gemaakt door 2. en 3.; git merge --abort kan hiervoor gebruikt worden.

  • Los de conflicten op. Git markeert de conflicten in de werkboom. Bewerk de bestanden in vorm en git add ze aan de index. Gebruik git commit om de deal te sluiten.

Je kunt het conflict oplossen met een aantal hulpmiddelen:

  • Gebruik een samenvoegtool. git mergetool om een ​​grafische mergetool te starten die je door het samenvoegen heen zal werken.

  • Kijk naar de verschillen. git diff zal een drie-weg diff tonen, waarbij veranderingen van zowel de HEAD als MERGE_HEAD versies worden gemarkeerd.

  • Kijk naar de verschillen van elke tak. git log --merge -p <path> zal eerst diffs tonen voor de HEAD versie en daarna de MERGE_HEAD versie.

  • Kijk naar de originelen. git show :1:filename toont de gemeenschappelijke voorouder, git show :2:filename toont de HEAD versie, en git show :3:filename toont de MERGE_HEAD versie.

Je kunt ook lezen over markeringen voor samenvoegconflicten en hoe je ze kunt oplossen in de Pro Git boeksectie Basic Merge-conflicten.


Antwoord 10

Voor Emacs-gebruikers die samenvoegconflicten semi-handmatig willen oplossen:

git diff --name-status --diff-filter=U

toont alle bestanden die conflictoplossing vereisen.

Open elk van deze bestanden één voor één, of allemaal tegelijk door:

emacs $(git diff --name-only --diff-filter=U)

Bij het bezoeken van een buffer die in Emacs moet worden bewerkt, typt u

ALT+x vc-resolve-conflicts

Hiermee worden drie buffers geopend (de mijne, die van hen en de uitvoerbuffer). Navigeer door op ‘n’ (volgende regio), ‘p’ (voorziene regio) te drukken. Druk op ‘a’ en ‘b’ om respectievelijk de mijne of hun regio naar de uitvoerbuffer te kopiëren. En/of bewerk de uitvoerbuffer direct.

Als u klaar bent: Druk op ‘q’. Emacs vraagt ​​of je deze buffer wilt bewaren: ja.
Na het beëindigen van een buffer markeert u het als opgelost door vanaf de terminal te starten:

git add FILENAME

Als u klaar bent met alle buffers type

git commit

om het samenvoegen te voltooien.


Antwoord 11

Bonus:

Als we het hebben over pull/fetch/merge in de vorige antwoorden, zou ik graag een interessante en productieve truc willen delen,

git pull --rebase

Dit bovenstaande commando is het meest bruikbare commando in mijn Git-leven dat veel tijd heeft bespaard.

Voordat u uw zojuist vastgelegde wijziging naar de externe server pusht, probeert u git pull --rebase in plaats van git pull en handmatige merge en het zal automatisch synchroniseer de laatste externe serverwijzigingen (met een fetch + merge) en zet je lokale laatste commit bovenaan in het Git-logboek. U hoeft zich geen zorgen te maken over handmatig trekken/samenvoegen.

In geval van een conflict, gebruik gewoon

git mergetool
git add conflict_file
git rebase --continue

Vind details op: Wat doet git pull rebase ?


Antwoord 12

Als je heel goed weet dat wijzigingen in een van de repositories niet belangrijk zijn en je alle wijzigingen wilt oplossen ten gunste van de andere, gebruik dan:

git checkout . --ours

om wijzigingen op te lossen in het voordeel van uw repository, of

git checkout . --theirs

om wijzigingen op te lossen ten gunste van de andere of de hoofdrepository.

Anders moet je een GUI-samenvoegtool gebruiken om de bestanden één voor één te doorlopen, zeg dat de samenvoegtool p4merge is, of schrijf iemands naam die je al hebt geïnstalleerd

git mergetool -t p4merge

en nadat je een bestand hebt voltooid, moet je het opslaan en sluiten, zodat het volgende wordt geopend.


Antwoord 13

Volg de volgende stappen om samenvoegconflicten in Git op te lossen:

  1. Controleer de Git-status:
    git-status

  2. Verkrijg de patchset:
    git fetch (check de juiste patch van je Git commit)

  3. Bekijk een lokale vestiging (temp1 in mijn voorbeeld hier):
    git checkout -b temp1

  4. Haal de recente inhoud uit de master:
    git pull –rebase origin master

  5. Start de mergetool en controleer de conflicten en repareer ze…en controleer de wijzigingen in de remote branch met je huidige branch:
    git mergetool

  6. Controleer de status opnieuw:
    git-status

  7. Verwijder de ongewenste bestanden die lokaal zijn gemaakt door mergetool, meestal maakt mergetool een extra bestand met de extensie *.orig. Verwijder dat bestand, want dat is slechts het duplicaat en corrigeer de wijzigingen lokaal en voeg de juiste versie van uw bestanden toe.
    git add #your_changed_correct_files

  8. Controleer de status opnieuw:
    git-status

  9. Leg de wijzigingen vast in hetzelfde commit-ID (dit vermijdt een nieuwe aparte patch-set):
    git commit –amend

  10. Push naar de master branch:
    git push (naar je Git-repository)


Antwoord 14

Er zijn drie stappen:

  1. Vind welke bestanden conflicten veroorzaken met het commando

     git status
    
  2. Controleer de bestanden waarin u de conflicten zou vinden die zijn gemarkeerd als

     <<<<<<<<head
     blablabla
    
  3. Verander het naar de manier waarop je het wilt, en leg dan vast met de commando’s

     git add solved_conflicts_files
     git commit -m 'merge msg'
    

Antwoord 15

U kunt samenvoegconflicten op een aantal manieren oplossen, zoals door anderen is beschreven.

Ik denk dat de echte sleutel is om te weten hoe veranderingen stromen met lokale en externe opslagplaatsen. De sleutel hiervoor is het begrijpen van trackingtakken. Ik heb ontdekt dat ik de tracking-branch zie als het ‘ontbrekende stuk in het midden’ tussen mij, mijn lokale, actuele bestandsdirectory en de remote die als oorsprong is gedefinieerd.

Ik heb er persoonlijk een gewoonte van gemaakt om twee dingen te doen om dit te voorkomen.

In plaats van:

git add .
git commit -m"some msg"

Wat twee nadelen heeft –

a) Alle nieuwe/gewijzigde bestanden worden toegevoegd en dat kan enkele ongewenste wijzigingen bevatten.
b) U kunt de bestandslijst niet eerst bekijken.

Dus in plaats daarvan doe ik:

git add file,file2,file3...
git commit # Then type the files in the editor and save-quit.

Op deze manier ben je bewuster over welke bestanden worden toegevoegd en kun je de lijst ook bekijken en wat meer nadenken terwijl je de editor voor het bericht gebruikt. Ik merk dat het ook mijn commit-berichten verbetert als ik een editor voor volledig scherm gebruik in plaats van de optie -m.

[Update – na verloop van tijd ben ik meer overgeschakeld naar:

git status # Make sure I know whats going on
git add .
git commit # Then use the editor

]

Ook (en relevanter voor uw situatie), probeer ik het volgende te vermijden:

git pull

of

git pull origin master.

omdat pull een samenvoeging impliceert en als je lokaal wijzigingen hebt die je niet wilt samenvoegen, kun je gemakkelijk samenvoegcode en/of samenvoegconflicten krijgen voor code die niet had moeten worden samengevoegd.

In plaats daarvan probeer ik te doen

git checkout master
git fetch   
git rebase --hard origin/master # or whatever branch I want.

Misschien vind je dit ook nuttig:

git branch, fork, fetch, merge, rebase en clone, wat zijn de verschillen?


Antwoord 16

Het antwoord van CoolAJ86 vat vrijwel alles samen. Als u wijzigingen in beide branches in hetzelfde stuk code heeft, moet u een handmatige merge uitvoeren. Open het conflicterende bestand in een teksteditor en u zou de volgende structuur moeten zien.

(Code not in Conflict)
>>>>>>>>>>>
(first alternative for conflict starts here)
Multiple code lines here
===========
(second alternative for conflict starts here)
Multiple code lines here too    
<<<<<<<<<<<
(Code not in conflict here)

Kies een van de alternatieven of een combinatie van beide op een manier die u wilt dat de nieuwe code is, terwijl u gelijktekens en punthaken verwijdert.

git commit -a -m "commit message"
git push origin master

Antwoord 17

Als je wilt mergen van branch test naar master, kun je deze stappen volgen:

Stap 1: Ga naar de vestiging

git checkout test

Stap 2:

git pull --rebase origin master

Stap 3: Als er conflicten zijn, ga dan naar deze bestanden om deze aan te passen.

Stap 4: voeg deze wijzigingen toe

git add #your_changes_files

Stap 5:

git rebase --continue

Stap 6: Als er nog steeds een conflict is, ga dan weer terug naar stap 3. Als er geen conflict is, doe dan het volgende:

git push origin +test

Stap 7: En dan is er geen conflict tussen test en master. Je kunt samenvoegen direct gebruiken.


Antwoord 18

git log --merge -p [[--] path]

Lijkt niet altijd voor mij te werken en laat meestal elke commit zien die verschillend was tussen de twee branches, dit gebeurt zelfs wanneer -- wordt gebruikt om het pad van het commando te scheiden.

p>

Wat ik doe om dit probleem te omzeilen, is twee opdrachtregels en in één keer openen

git log ..$MERGED_IN_BRANCH --pretty=full -p [path]

en in de andere

git log $MERGED_IN_BRANCH.. --pretty=full -p [path]

$MERGED_IN_BRANCH vervangen door de branch die ik heb samengevoegd en [path] door het conflicterende bestand. Dit commando zal alle commits loggen, in patchvorm, tussen (..) twee commits. Als je één kant leeg laat, zoals in de bovenstaande commando’s, zal git automatisch HEAD gebruiken (in dit geval de branch waarin je merged).

Hierdoor kun je zien welke commits in het bestand in de twee branches zijn gegaan nadat ze uit elkaar gingen. Het maakt het meestal veel gemakkelijker om conflicten op te lossen.


Antwoord 19

patience

gebruiken

Voor een groot samenvoegconflict leverde het gebruik van patience goede resultaten op voor mij. Het zal proberen blokken te matchen in plaats van individuele regels.

Als je bijvoorbeeld de inspringing van je programma verandert, komt de standaard Git merge-strategie soms overeen met enkele accolades { die bij verschillende functies horen. Dit wordt vermeden met patience:

git merge -s recursive -X patience other-branch

Uit de documentatie:

With this option, merge-recursive spends a little extra time to avoid 
mismerges that sometimes occur due to unimportant matching lines 
(e.g., braces from distinct functions). Use this when the branches to 
be merged have diverged wildly.

Vergelijking met de gemeenschappelijke voorouder

Als je een merge-conflict hebt en wilt zien wat anderen in gedachten hadden bij het wijzigen van hun branch, is het soms makkelijker om hun branch rechtstreeks te vergelijken met de gemeenschappelijke voorouder (in plaats van onze branch). Daarvoor kun je merge-base gebruiken:

git diff $(git merge-base <our-branch> <their-branch>) <their-branch>

Meestal wilt u alleen de wijzigingen voor een bepaald bestand zien:

git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>

Antwoord 20

Vanaf 12 december 2016 kun je branches samenvoegen en conflicten oplossen op github.com

Dus, als je geen gebruik wilt maken van de opdrachtregel of tools van derden die hier worden aangeboden uit oudere antwoorden, gebruik dan de native tool van GitHub.

Deze blogpost legt in detail uit, maar de basis is dat bij het ‘samenvoegen’ van twee branches via de gebruikersinterface, je nu een optie ‘conflicten oplossen’ ziet die je naar een editor brengt waarmee je deze samenvoegconflicten kunt oplossen.

voer hier de afbeeldingsbeschrijving in


Antwoord 21

Ik volg altijd de onderstaande stappen om conflicten te voorkomen.

  • git checkout master (Kom naar de master branch)
  • git pull (Update je master om de laatste code te krijgen)
  • git checkout -b mybranch (Bekijk een nieuwe a-branch en begin aan die branch te werken, zodat je master altijd bovenaan de trunk blijft.)
  • git add . en git commit en git push (op je lokale vestiging na uw wijzigingen)
  • git checkout master (Kom terug naar je master)

Nu kun je hetzelfde doen en zoveel lokale filialen onderhouden als je wilt en tegelijkertijd werken door gewoon een git checkout naar je filiaal te doen wanneer dat nodig is.


Antwoord 22

Samenvoegconflicten kunnen in verschillende situaties voorkomen:

  • Bij het uitvoeren van git fetch en vervolgens git merge
  • Bij het uitvoeren van git fetch en vervolgens git rebase
  • Bij het uitvoeren van git pull (wat in feite gelijk is aan een van de bovengenoemde voorwaarden)
  • Bij het uitvoeren van git stash pop
  • Als je git-patches toepast (toezeggingen die worden geëxporteerd naar bestanden om te worden overgedragen, bijvoorbeeld per e-mail)

Je moet een samenvoegtool installeren die compatibel is met Git om de conflicten op te lossen. Ik gebruik persoonlijk KDiff3, en ik vond het leuk en handig. Je kunt de Windows-versie hier downloaden:

https://sourceforge.net/projects/kdiff3/files/

BTW, als je Git Extensions installeert, is er een optie in de installatiewizard om Kdiff3 te installeren.

Stel vervolgens de Git-configuratie in om KDiff3 te gebruiken als zijn mergetool:

$ git config --global --add merge.tool kdiff3
$ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add mergetool.kdiff3.trustExitCode false
$ git config --global --add diff.guitool kdiff3
$ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add difftool.kdiff3.trustExitCode false

(Vergeet niet om het pad te vervangen door het werkelijke pad van het KDiff3 EXE-bestand.)

Elke keer dat je een samenvoegconflict tegenkomt, hoef je alleen maar dit commando uit te voeren:

$ git mergetool

Vervolgens wordt Kdiff3 geopend en wordt eerst geprobeerd de samenvoegconflicten automatisch op te lossen. De meeste conflicten worden spontaan opgelost en de rest moet je handmatig oplossen.

Zo ziet Kdiff3 eruit:

Voer hier de afbeeldingsbeschrijving in

Als je klaar bent, sla je het bestand op en het gaat naar het volgende bestand met een conflict en je doet hetzelfde opnieuw totdat alle conflicten zijn opgelost.

Om te controleren of alles succesvol is samengevoegd, voert u de opdracht mergetool opnieuw uit. Je zou dit resultaat moeten krijgen:

$ git mergetool
No files need merging

Antwoord 23

Dit antwoord is om een ​​alternatief toe te voegen voor die Vim-gebruikers zoals ik die het liefst alles binnen de editor doen.


TL;DR

Voer hier de afbeeldingsbeschrijving in


Tpope bedacht deze geweldige plug-in voor Vim genaamd vluchteling. Eenmaal geïnstalleerd, kun je :Gstatus uitvoeren om de bestanden met conflicten te controleren en :Gdiff om Git te openen in een samenvoeging in drie richtingen.

Eenmaal in de three-way merge, laat fugitive je de wijzigingen krijgen van een van de branches die je aan het mergen bent op de volgende manier:

  • :diffget //2, krijg wijzigingen van de originele (HEAD) branch:
  • :diffget //3, krijg wijzigingen van samenvoegende tak:

Als u klaar bent met het samenvoegen van het bestand, typt u :Gwrite in de samengevoegde buffer.

Vimcasts heeft een geweldige video uitgebracht met uitleg deze stappen in detail.


Antwoord 24

GitLens voor Visual Studio-code

Je kunt GitLens voor Visual Studio Code proberen. De belangrijkste kenmerken zijn:

3. Eenvoudig conflicten oplossen

Ik vind deze functie al leuk:

Voer hier de afbeeldingsbeschrijving in

2. Huidige regel schuld.

Voer hier de afbeeldingsbeschrijving in

3. Goot schuld

Voer hier de afbeeldingsbeschrijving in

4. Statusbalk Schuld

Voer hier de afbeeldingsbeschrijving in

En er zijn veel functies. Je kunt ze hier bekijken.


Antwoord 25

git fetch <br>
git checkout **your branch**<br>
git rebase master<br>

In deze stap probeert u het conflict op te lossen met de IDE van uw voorkeur.

Je kunt deze link om te controleren hoe het conflict in het bestand kan worden opgelost.

git add<br>
git rebase --continue<br>
git commit --amend<br>
git push origin HEAD:refs/drafts/master  (push like a drafts)<br>

Nu is alles in orde en vind je je commit in Gerrit.


Antwoord 26

Ik begreep wat een samenvoegconflict was, maar toen ik de uitvoer van git diff zag, leek het me eerst onzin:

git diff
++<<<<<<< HEAD
 + display full last name boolean in star table
++=======
+ users viewer.id/star.id, and conversation uses user.id
+
++>>>>>>> feat/rspec-tests-for-cancancan

Maar hier heeft me geholpen:

  • Alles tussen <<<<<<< en ======= is wat in één bestand, en

  • Alles tussen ======= en >>>>>>> is wat in het andere bestand

  • Dus letterlijk alles wat je hoeft te doen is het bestand met de samenvoegconflicten te openen en die regels uit beide vertakkingen te verwijderen (of ze gewoon hetzelfde te maken), en de merge zal onmiddellijk slagen . Probleem opgelost!


Antwoord 27

Een veiligere manier om conflicten op te lossen is om git-mediate te gebruiken (de algemene voorgestelde oplossingen hier zijn nogal foutgevoelig imho).

Zie dit bericht voor een korte introductie over het gebruik ervan.


Antwoord 28

Voor degenen die Visual Studio gebruiken (Visual Studio 2015 in mijn geval)

  1. Sluit uw project in Visual Studio. Vooral in grote projecten heeft Visual Studio de neiging om in paniek te raken bij het samenvoegen met behulp van de gebruikersinterface.

  2. Voer het samenvoegen uit in een opdrachtprompt.

    git checkout target_branch

    git merge source_branch

  3. Open vervolgens het project in Visual Studio en ga naar Team Explorer > Branch. Nu is er een bericht dat zegt Samenvoegen is in behandeling en conflicterende bestanden worden direct onder het bericht weergegeven.

  4. Klik op het conflicterende bestand en u krijgt de optie om Samenvoegen, Vergelijken, Bron nemen en Take Doel. De samenvoegtool in Visual Studio is heel gemakkelijk te gebruiken.


Antwoord 29

Probeer Visual Studio Code om te bewerken als je dat nog niet bent.

Nadat u probeert samen te voegen (en in samenvoegconflicten belandt), detecteert Visual Studio Code automatisch de samenvoegconflicten.

Het kan je heel goed helpen door de wijzigingen aan de originele te tonen en of je incoming of

moet accepteren

current change (wat de oorspronkelijke wijziging betekent vóór het samenvoegen)’.

Het heeft me geholpen en het kan ook voor jou werken!

PS: het werkt alleen als je Git hebt geconfigureerd met met je code en Visual Studio-code.


Antwoord 30

Ik gebruik de Visual Studio Code van Microsoft voor het oplossen van conflicten. Het is heel eenvoudig te gebruiken. Ik houd mijn project open in de werkruimte. Het detecteert en benadrukt conflicten. Bovendien geeft het GUI-opties om de wijziging te selecteren die ik wil behouden van HEAD of inkomend.

Voer hier de afbeeldingsbeschrijving in

LEAVE A REPLY

Please enter your comment!
Please enter your name here

7 + five =

Other episodes