git-merge(1)
git-merge(1)
Namn
git-merge - sammanfoga två eller flera utvecklingshistoriker
Synopsis
git merge [-n] [--stat] [--compact-summary] [--no-commit] [--squash] [--[no-]edit]
[--no-verify] [-s <strategi>] [-X <strategialternativ>] [-S[<nyckel-id>]]
[--[no-]allow-unrelated-histories]
[--[no-]rerere-autoupdate] [-m <meddelande>] [-F <fil>]
[--into-name <gren>] [<commit>...]
git merge (--continue | --abort | --quit)
Beskrivning
Infogar ändringar från de angivna commit-objekten, räknat från den punkt där deras historiker skiljde sig från den aktuella grenen, in i den aktuella grenen. Kommandot används av git pull för att ta in ändringar från ett annat arkiv, men kan också användas direkt för att slå samman ändringar från en gren till en annan.
Anta att följande historik finns och att den aktuella grenen är master:
A---B---C topic
/
D---E---F---G master
Då kommer git merge topic att spela upp ändringarna som gjorts på grenen topic sedan den skiljde sig från master (det vill säga från E) fram till dess aktuella commit (C) ovanpå master. Resultatet sparas i en ny commit tillsammans med namnen på de två föräldra-commit:arna och ett loggmeddelande från användaren som beskriver ändringarna. Före åtgärden sätts ORIG_HEAD till spetsen på den aktuella grenen (G).
A---B---C topic
/ \
D---E---F---G---H master
En sammanslagning stoppas om det uppstår en konflikt som inte kan lösas automatiskt, eller om --no-commit angavs när sammanslagningen startades. Vid den punkten kan du köra git merge --abort eller git merge --continue.
git merge --abort avbryter sammanslagningsprocessen och försöker återskapa tillståndet före sammanslagningen. Om det fanns ocommittade ändringar när sammanslagningen startades, särskilt om dessa ändringar dessutom ändrades efter att sammanslagningen hade startats, kan git merge --abort i vissa fall inte återskapa det ursprungliga tillståndet.
Varning: Att köra git merge med icke-triviala ocommittade ändringar avråds från. Det är möjligt, men vid konflikt kan du hamna i ett tillstånd som är svårt att backa ur.
Alternativ
--commit, --no-commit
Utför sammanslagningen och committa resultatet. Detta alternativ kan användas för att upphäva --no-commit.
Med --no-commit utförs sammanslagningen, men Git stannar precis innan en merge-commit skapas. Det ger användaren möjlighet att granska och justera resultatet innan det committas.
Observera att fast-forward-uppdateringar inte skapar någon merge-commit och därför inte kan stoppas med --no-commit. Om du vill säkerställa att grenen inte ändras eller uppdateras av merge-kommandot, använd --no-ff tillsammans med --no-commit.
--edit, -e, --no-edit
Öppna en editor före commit av en lyckad mekanisk sammanslagning så att användaren kan redigera det automatiskt skapade merge-meddelandet och förklara eller motivera sammanslagningen. Alternativet --no-edit kan användas för att acceptera det automatiskt skapade meddelandet, men det avråds normalt från. --edit eller -e är fortfarande användbart om du ger ett utkast med -m på kommandoraden och vill redigera det i editorn.
Äldre skript kan bero på det historiska beteendet där användaren inte fick redigera merge-loggmeddelandet. De kommer att se en editor öppnas när de kör git merge. För att förenkla anpassning av sådana skript kan miljövariabeln GIT_MERGE_AUTOEDIT sättas till no i början av skripten.
--cleanup=<läge>
Anger hur merge-meddelandet ska rensas innan commit. Se git-commit(1) för detaljer. Om <läge> har värdet scissors läggs en saxmarkör till i MERGE_MSG innan meddelandet skickas vidare till commit-mekanismen vid en merge-konflikt.
--ff, --no-ff, --ff-only
Anger hur sammanslagningen hanteras när historiken som slås in redan är en ättling till den aktuella historiken. --ff är standard, utom när en annoterad, och möjligen signerad, tagg som inte ligger på sin naturliga plats under refs/tags/ slås samman. I det fallet antas --no-ff.
Med --ff löses sammanslagningen som fast-forward när det är möjligt. Då uppdateras endast grenpekaren så att den pekar på den gren som slås in, utan att en merge-commit skapas. När fast-forward inte är möjligt skapas en merge-commit.
Med --no-ff skapas alltid en merge-commit, även när sammanslagningen hade kunnat göras som fast-forward.
Med --ff-only tillåts endast fast-forward. Om det inte är möjligt vägrar Git att slå samman och avslutar med en statuskod som inte är noll.
-S[<nyckel-id>], --gpg-sign[=<nyckel-id>], --no-gpg-sign
GPG-signera den resulterande merge-commit:en. Argumentet <nyckel-id> är valfritt och använder committarens identitet som standard. Om det anges måste det sitta direkt ihop med alternativet utan mellanslag. --no-gpg-sign kan användas för att upphäva både konfigurationsvariabeln commit.gpgSign och tidigare --gpg-sign.
--log[=<n>], --no-log
Utöver grennamn fylls loggmeddelandet med enradsbeskrivningar från högst <n> av de faktiska commit:ar som slås samman. Se även git-fmt-merge-msg(1).
Med --no-log listas inga enradsbeskrivningar från de commit:ar som slås samman.
--signoff, --no-signoff
Lägg till en Signed-off-by-trailer av committaren i slutet av commit-loggmeddelandet. Betydelsen av en signoff beror på projektet. Den kan exempelvis intyga att committaren har rätt att bidra med arbetet under projektets licens, eller att personen accepterar en bidragsförklaring som Developer Certificate of Origin. Se developercertificate.org för den variant som används av Linuxkärnan och Git-projektet. Läs projektets dokumentation eller fråga projektledningen för att förstå hur signoff används där.
--no-signoff upphäver ett tidigare --signoff på kommandoraden.
Git har inte, och kommer inte att ha, någon konfigurationsvariabel för att aktivera --signoff som standard. Se posten commit.signoff i gitfaq(7) för mer information.
--stat, -n, --no-stat
Visa diffstatistik i slutet av sammanslagningen. Diffstatistiken styrs även av konfigurationsalternativet merge.stat.
Med -n eller --no-stat visas ingen diffstatistik i slutet av sammanslagningen.
--compact-summary
Visa en kompakt sammanfattning i slutet av sammanslagningen.
--squash, --no-squash
Skapa arbetskatalogens och indexets tillstånd som om en verklig sammanslagning hade skett, bortsett från merge-informationen. Git gör ingen commit, flyttar inte HEAD och skriver inte $GIT_DIR/MERGE_HEAD så att nästa git commit skulle skapa en merge-commit. Detta gör det möjligt att skapa en enda commit ovanpå den aktuella grenen med samma effekt som att slå samman en annan gren, eller flera vid en octopus-sammanslagning.
Med --no-squash utförs sammanslagningen och resultatet committas. Detta kan användas för att upphäva --squash.
Med --squash är --commit inte tillåtet och kommer att misslyckas.
--verify, --no-verify
Som standard körs krokarna pre-merge och commit-msg. Med --no-verify hoppas dessa över. Se även githooks(5).
-s <strategi>, --strategy=<strategi>
Använd den angivna merge-strategin. Alternativet kan anges flera gånger för att ange strategier i den ordning de ska provas. Om inget -s anges används en inbyggd lista med strategier: ort vid sammanslagning av ett enda huvud och octopus annars.
-X <alternativ>, --strategy-option=<alternativ>
Skicka ett strategispecifikt alternativ vidare till merge-strategin.
--verify-signatures, --no-verify-signatures
Verifiera att spets-commit:en på sidogrenen som slås samman är signerad med en giltig nyckel. I den normala tillitsmodellen betyder det att signeringsnyckeln har signerats av en betrodd nyckel. Om sidogrenens spets inte är signerad med en giltig nyckel avbryts sammanslagningen.
--summary, --no-summary
Synonymer till --stat och --no-stat. De är föråldrade och kommer att tas bort i framtiden.
-q, --quiet
Arbeta tyst. Implicerar --no-progress.
-v, --verbose
Var utförlig.
--progress, --no-progress
Aktivera eller inaktivera progressrapportering uttryckligen. Om inget anges visas progress om standardfel är anslutet till en terminal. Alla merge-strategier stöder inte nödvändigtvis progressrapportering.
--autostash, --no-autostash
Skapa automatiskt en tillfällig stash-post innan åtgärden börjar, lagra den i refen MERGE_AUTOSTASH och applicera den efter att åtgärden avslutats. Det betyder att du kan köra åtgärden i en arbetskatalog med ändringar. Använd med försiktighet: den sista appliceringen av stashen efter en lyckad sammanslagning kan leda till icke-triviala konflikter.
--allow-unrelated-histories
Som standard vägrar git merge att slå samman historiker som inte har en gemensam anfader. Detta alternativ kan användas för att upphäva säkerhetsspärren när historiker från två projekt som startat oberoende av varandra ska slås samman. Eftersom detta är mycket ovanligt finns ingen konfigurationsvariabel för att aktivera det som standard, och någon sådan kommer inte att läggas till.
-m <meddelande>
Ange commit-meddelandet som ska användas för merge-commit:en, om en sådan skapas.
Om --log anges läggs en kortlogg över de commit:ar som slås samman till efter det angivna meddelandet.
Kommandot git fmt-merge-msg kan användas för att skapa ett bra standardmeddelande vid automatiserade git merge-anrop. Det automatiska meddelandet kan innehålla grenbeskrivningen.
--into-name <gren>
Förbered standardmeddelandet som om sammanslagningen gjordes till grenen <gren>, i stället för till den verkliga grenen som sammanslagningen görs till.
-F <fil>, --file=<fil>
Läs commit-meddelandet som ska användas för merge-commit:en från <fil>, om en merge-commit skapas.
Om --log anges läggs en kortlogg över commit:arna som slås samman till efter det angivna meddelandet.
--rerere-autoupdate, --no-rerere-autoupdate
Efter att rerere-mekanismen har återanvänt en inspelad lösning för den aktuella konflikten och uppdaterat filerna i arbetskatalogen, tillåt den även att uppdatera indexet med resultatet. --no-rerere-autoupdate är ett bra sätt att dubbelkontrollera vad git-rerere(1) gjorde och fånga möjliga felaktiga sammanslagningar innan resultatet läggs till i indexet med ett separat git-add(1).
--overwrite-ignore, --no-overwrite-ignore
Skriv tyst över ignorerade filer från merge-resultatet. Detta är standardbeteendet. Använd --no-overwrite-ignore för att avbryta i stället.
--abort
Avbryt den pågående konfliktlösningsprocessen och försök återskapa tillståndet före sammanslagningen. Om en autostash-post finns appliceras den på arbetskatalogen.
Om det fanns ocommittade ändringar i arbetskatalogen när sammanslagningen startades kan git merge --abort i vissa fall inte återskapa dessa ändringar. Därför rekommenderas att du alltid committar eller stashar dina ändringar innan du kör git merge.
git merge --abort motsvarar git reset --merge när MERGE_HEAD finns, om inte MERGE_AUTOSTASH också finns. I det fallet applicerar git merge --abort stash-posten på arbetskatalogen, medan git reset --merge sparar de stashade ändringarna i stash-listan.
--quit
Glöm den pågående sammanslagningen. Lämna indexet och arbetskatalogen som de är. Om MERGE_AUTOSTASH finns sparas stash-posten i stash-listan.
--continue
Efter att git merge har stoppats på grund av konflikter kan du avsluta sammanslagningen genom att köra git merge --continue. Se avsnittet ”Hur konflikter löses” nedan.
<commit>...
Commit:ar, vanligtvis andra grenhuvuden, som ska slås samman in i vår gren. Om mer än en commit anges skapas en sammanslagning med fler än två föräldrar, kallad en octopus-merge.
Om ingen commit anges på kommandoraden slås de remote-tracking-grenar samman som den aktuella grenen är konfigurerad att använda som upstream. Se även konfigurationsavsnittet i denna manualsida.
När FETCH_HEAD anges, och ingen annan commit anges, slås de grenar samman som spelades in i filen .git/FETCH_HEAD av föregående git fetch för sammanslagning med den aktuella grenen.
Kontroller före sammanslagning
Innan externa ändringar appliceras bör du se till att ditt eget arbete är i gott skick och committat lokalt, så att det inte skrivs över om konflikter uppstår. Se även git-stash(1). git pull och git merge stoppar utan att göra något när lokala ocommittade ändringar överlappar filer som git pull eller git merge kan behöva uppdatera.
För att undvika att orelaterade ändringar hamnar i merge-commit:en avbryter git pull och git merge också om det finns ändringar registrerade i indexet relativt HEAD-commit:en. Smala undantag kan finnas beroende på merge-strategi, men i normalfallet måste indexet matcha HEAD.
Om alla angivna commit:ar redan är förfäder till HEAD avslutar git merge tidigt med meddelandet ”Already up to date.”
Fast-forward-sammanslagning
Ofta är den aktuella grenens huvud en anfader till den angivna commit:en. Detta är det vanligaste fallet, särskilt när kommandot anropas från git pull: du följer ett upstream-arkiv, har inte gjort några lokala commit:ar och vill uppdatera till en nyare upstream-revision. I detta fall behövs ingen ny commit för att lagra den kombinerade historiken. I stället uppdateras HEAD, tillsammans med indexet, så att den pekar på den angivna commit:en, utan att en extra merge-commit skapas.
Detta beteende kan undertryckas med --no-ff.
Verklig sammanslagning
Förutom vid fast-forward-sammanslagning måste grenarna som slås samman bindas ihop av en merge-commit som har båda som föräldrar.
En sammanslagen version som förenar ändringarna från alla grenar committas, och HEAD, indexet och arbetskatalogen uppdateras till den. Det är möjligt att ha ändringar i arbetskatalogen så länge de inte överlappar; uppdateringen bevarar dem.
När det inte är uppenbart hur ändringarna ska förenas sker följande:
- HEAD-pekaren stannar där den är.
- Refen MERGE_HEAD sätts till det andra grenhuvudet.
- Sökvägar som slås samman rent uppdateras både i indexfilen och i arbetskatalogen.
- För konfliktfyllda sökvägar lagrar indexfilen upp till tre versioner: steg 1 lagrar versionen från den gemensamma anfadern, steg 2 versionen från HEAD och steg 3 versionen från MERGE_HEAD. Du kan inspektera stegen med git ls-files -u. Filerna i arbetskatalogen innehåller resultatet av merge-operationen, det vill säga en trevägssammanslagning med de välkända konfliktmarkörerna <<<, === och >>>.
- En ref med namnet AUTO_MERGE skrivs och pekar på ett träd som motsvarar det aktuella innehållet i arbetskatalogen, inklusive konfliktmarkörer för textkonflikter. Denna ref skrivs endast när merge-strategin ort används, vilket är standard.
- Inga andra ändringar görs. Särskilt bevaras de lokala ändringar du hade innan sammanslagningen startade, och indexposterna för dem förblir som de var, det vill säga matchande HEAD.
Om du försökte göra en sammanslagning som ledde till komplexa konflikter och vill börja om kan du återställa med git merge --abort.
Sammanslagning av tagg
När en annoterad, och möjligen signerad, tagg slås samman skapar Git alltid en merge-commit även om en fast-forward-sammanslagning är möjlig. Commit-meddelandets mall förbereds med taggmeddelandet. Om taggen är signerad rapporteras dessutom signaturkontrollen som en kommentar i meddelandemallen. Se även git-tag(1).
När du bara vill integrera arbetet som leder fram till den commit som råkar vara taggad, till exempel vid synkronisering med en upstream-releasepunkt, kanske du inte vill skapa en onödig merge-commit.
I ett sådant fall kan du själv ”packa upp” taggen innan du skickar den till git merge, eller ange --ff-only om du inte har eget arbete. Exempel:
git fetch origin git merge v1.2.3^0 git merge --ff-only v1.2.3
Hur konflikter presenteras
Under en sammanslagning uppdateras filerna i arbetskatalogen så att de återspeglar resultatet. Bland ändringarna relativt den gemensamma anfadern infogas icke-överlappande ändringar oförändrade i slutresultatet. Det betyder att om du ändrat en del av filen medan den andra sidan lämnat samma del orörd, eller tvärtom, går ändringen in utan konflikt. När båda sidor ändrat samma område kan Git däremot inte slumpmässigt välja en sida, utan ber dig lösa konflikten genom att lämna kvar vad båda sidor gjorde i området.
Som standard använder Git samma stil som programmet merge från RCS-sviten för att visa ett konfliktområde:
Här är rader som antingen är oförändrade från den gemensamma anfadern, eller rent lösta eftersom bara en sida ändrade dem, eller rent lösta eftersom båda sidor ändrade dem på samma sätt. <<<<<<< yours:sample.txt Konfliktlösning är svårt; vi går och handlar i stället. ======= Git gör konfliktlösning enkelt. >>>>>>> theirs:sample.txt Och här finns ännu en rad som är rent löst eller oförändrad.
Området där ett par motstridiga ändringar skett markeras med <<<<<<<, ======= och >>>>>>>. Delen före ======= är normalt din sida, och delen efter är normalt deras sida.
Standardformatet visar inte vad originalet sade i konfliktområdet. Du kan inte se hur många rader som tagits bort och ersatts på din sida. Du ser bara att din sida vill säga att det är svårt och föredrar att gå och handla, medan den andra sidan vill hävda att Git gör konfliktlösning enkelt.
En alternativ stil kan användas genom att sätta konfigurationsvariabeln merge.conflictStyle till diff3 eller zdiff3. I diff3-stil kan konflikten ovan se ut så här:
Här är rader som antingen är oförändrade från den gemensamma anfadern, eller rent lösta eftersom bara en sida ändrade dem, <<<<<<< yours:sample.txt eller rent lösta eftersom båda sidor ändrade dem på samma sätt. Konfliktlösning är svårt; vi går och handlar i stället. ||||||| base:sample.txt eller rent lösta eftersom båda sidor ändrade dem identiskt. Konfliktlösning är svårt. ======= eller rent lösta eftersom båda sidor ändrade dem på samma sätt. Git gör konfliktlösning enkelt. >>>>>>> theirs:sample.txt Och här finns ännu en rad som är rent löst eller oförändrad.
I zdiff3-stil kan den se ut så här:
Här är rader som antingen är oförändrade från den gemensamma anfadern, eller rent lösta eftersom bara en sida ändrade dem, eller rent lösta eftersom båda sidor ändrade dem på samma sätt. <<<<<<< yours:sample.txt Konfliktlösning är svårt; vi går och handlar i stället. ||||||| base:sample.txt eller rent lösta eftersom båda sidor ändrade dem identiskt. Konfliktlösning är svårt. ======= Git gör konfliktlösning enkelt. >>>>>>> theirs:sample.txt Och här finns ännu en rad som är rent löst eller oförändrad.
Utöver markörerna <<<<<<<, ======= och >>>>>>> används ytterligare markören ||||||| som följs av originaltexten. Då kan du se att originalet bara konstaterade ett faktum, att din sida gav upp och gick med på detta, medan den andra sidan försökte ha en mer positiv hållning. Ibland kan originalet hjälpa dig att hitta en bättre lösning.
Hur konflikter löses
Efter att en konflikt uppstått kan du göra två saker:
- Avstå från att slå samman. Den enda städning som behövs är att återställa indexfilen till HEAD-commit:en för att backa punkt 2 och städa upp ändringar i arbetskatalogen som gjorts av punkt 2 och 3. git merge --abort kan användas för detta.
- Lös konflikterna. Git markerar konflikterna i arbetskatalogen. Redigera filerna till rätt form och kör git add på dem så att de läggs i indexet. Använd git commit eller git merge --continue för att avsluta. Det senare kommandot kontrollerar att en avbruten sammanslagning faktiskt pågår innan det anropar git commit.
Du kan arbeta igenom konflikten med flera verktyg:
- Använd ett merge-verktyg. git mergetool startar ett grafiskt merge-verktyg som hjälper dig igenom sammanslagningen.
- Titta på differenserna. git diff visar en trevägsdiff som markerar ändringar från både HEAD- och MERGE_HEAD-versionerna. git diff AUTO_MERGE visar vilka ändringar du hittills gjort för att lösa textkonflikter.
- Titta på differenser från varje gren. git log --merge -p <sökväg> visar först differenser för HEAD-versionen och sedan för MERGE_HEAD-versionen.
- Titta på originalen. git show :1:filnamn visar den gemensamma anfadern, git show :2:filnamn visar HEAD-versionen och git show :3:filnamn visar MERGE_HEAD-versionen.
Exempel
Slå samman grenarna fixes och enhancements ovanpå den aktuella grenen och skapa en octopus-merge:
$ git merge fixes enhancements
Slå samman grenen obsolete in i den aktuella grenen med merge-strategin ours:
$ git merge -s ours obsolete
Slå samman grenen maint in i den aktuella grenen, men skapa inte en ny commit automatiskt:
$ git merge --no-commit maint
Detta kan användas när du vill lägga till ytterligare ändringar i sammanslagningen eller skriva ett eget merge-commit-meddelande.
Du bör undvika att missbruka detta alternativ för att smyga in större ändringar i en merge-commit. Små justeringar, som att höja versionsnamn, kan vara acceptabla.
Merge-strategier
Merge-mekanismen i git merge och git pull låter backend-strategier väljas med alternativet -s. Vissa strategier kan också ta egna alternativ, som kan skickas med -X<alternativ> till git merge och/eller git pull.
ort
Detta är standardstrategin vid pull eller merge av en enda gren. Strategin kan endast lösa två huvuden med en trevägsmerge-algoritm. När det finns mer än en gemensam anfader som kan användas för trevägssammanslagning skapar den ett sammanslaget träd av de gemensamma anfäderna och använder detta som referensträd. Tester på verkliga merge-commit:ar från utvecklingshistoriken för Linux 2.6-kärnan har rapporterat att detta ger färre konflikter utan att orsaka felaktiga sammanslagningar. Strategin kan dessutom upptäcka och hantera sammanslagningar som omfattar namnbyten. Den använder inte upptäckta kopior. Namnet är en akronym för ”Ostensibly Recursive’s Twin” och kommer av att algoritmen skrevs som ersättning för den tidigare standardalgoritmen recursive.
Om sökvägen är en submodul och submodulens commit på ena sidan är en ättling till submodulens commit på den andra sidan, försöker Git göra fast-forward till ättlingen. Annars behandlar Git detta som en konflikt och föreslår som lösning en submodul-commit som är ättling till de konfliktande commit:arna, om en sådan finns.
Strategin ort kan ta följande alternativ:
ours
Detta alternativ tvingar konfliktande hunks att lösas automatiskt genom att föredra vår version. Ändringar från det andra trädet som inte står i konflikt med vår sida återspeglas i merge-resultatet. För binära filer tas hela innehållet från vår sida.
Detta ska inte förväxlas med merge-strategin ours, som inte ens tittar på vad det andra trädet innehåller. Den kastar bort allt som det andra trädet gjorde och deklarerar att vår historik innehåller allt som hänt där.
theirs
Detta är motsatsen till ours. Observera att det, till skillnad från ours, inte finns någon merge-strategi theirs som kan förväxlas med detta merge-alternativ.
ignore-space-change, ignore-all-space, ignore-space-at-eol, ignore-cr-at-eol
Behandlar rader med angiven typ av blankstegsändring som oförändrade vid trevägssammanslagning. Blankstegsändringar som blandas med andra ändringar på samma rad ignoreras inte. Se även git-diff(1) med -b, -w, --ignore-space-at-eol och --ignore-cr-at-eol.
- Om deras version endast introducerar blankstegsändringar på en rad används vår version.
- Om vår version introducerar blankstegsändringar men deras version innehåller en betydande ändring används deras version.
- Annars fortsätter sammanslagningen på vanligt sätt.
renormalize
Gör en virtuell utcheckning och incheckning av alla tre steg för varje fil som behöver en trevägssammanslagning. Alternativet är avsett när grenar med olika clean-filter eller regler för radslutsnormalisering slås samman. Se avsnittet om sammanslagning av grenar med olika checkin-/checkout-attribut i gitattributes(5).
no-renormalize
Inaktiverar renormalize. Detta åsidosätter konfigurationsvariabeln merge.renormalize.
find-renames[=<n>]
Aktivera namnbytesdetektering, eventuellt med angiven likhetströskel. Detta är standard. Det åsidosätter konfigurationsvariabeln merge.renames. Se även git-diff(1) med --find-renames.
rename-threshold=<n>
Föråldrad synonym till find-renames=<n>.
no-renames
Inaktivera namnbytesdetektering. Detta åsidosätter merge.renames. Se även git-diff(1) med --no-renames.
histogram
Föråldrad synonym till diff-algorithm=histogram.
patience
Föråldrad synonym till diff-algorithm=patience.
diff-algorithm=(histogram|minimal|myers|patience)
Använd en annan diff-algoritm vid sammanslagning. Detta kan hjälpa till att undvika felaktiga sammanslagningar som orsakas av oviktiga matchande rader, till exempel klamrar från olika funktioner. Se även git-diff(1) med --diff-algorithm. Observera att ort som standard använder diff-algorithm=histogram, medan vanliga diffar för närvarande använder inställningen diff.algorithm.
subtree[=<sökväg>]
Detta är en mer avancerad form av strategin subtree. Strategin gissar hur två träd måste förskjutas för att matcha varandra vid sammanslagning. Med detta alternativ används den angivna sökvägen som prefix, eller tas bort från början, för att få trädens form att matcha.
recursive
Detta är numera en synonym till ort. Den var en alternativ implementation fram till v2.49.0 men omdirigerades i v2.50.0 till att betyda ort. Den tidigare recursive-strategin var standardstrategin för att lösa två huvuden från Git v0.99.9k till v2.33.0.
resolve
Kan endast lösa två huvuden, det vill säga den aktuella grenen och en annan gren som du drog in, med en trevägsmerge-algoritm. Den försöker noggrant upptäcka criss-cross-ambiguiteter. Den hanterar inte namnbyten.
octopus
Löser fall med fler än två huvuden, men vägrar göra en komplex sammanslagning som kräver manuell lösning. Den är främst avsedd för att samla topic-grenhuvuden. Detta är standardstrategin vid pull eller merge av fler än en gren.
ours
Löser valfritt antal huvuden, men resultatträdet blir alltid den aktuella grenens huvud, vilket i praktiken ignorerar alla ändringar från alla andra grenar. Den är avsedd för att ersätta gammal utvecklingshistorik från sidogrenar. Observera att detta skiljer sig från alternativet -Xours till strategin ort.
subtree
Detta är en modifierad ort-strategi. När träden A och B slås samman och B motsvarar ett underträd till A, justeras B först så att det matchar trädstrukturen i A, i stället för att läsa träden på samma nivå. Denna justering görs också för det gemensamma anfaderträdet.
Med strategier som använder trevägssammanslagning, inklusive standardstrategin ort, gäller att om en ändring görs på båda grenarna men senare återställs på ena grenen, kommer ändringen att finnas i det sammanslagna resultatet. Vissa upplever detta som förvirrande. Det sker eftersom bara huvudena och merge-basen beaktas vid sammanslagning, inte de enskilda commit:arna. Merge-algoritmen betraktar därför den återställda ändringen som ingen ändring alls och ersätter med den ändrade versionen.
Konfiguration
branch.<namn>.mergeOptions
Anger standardalternativ för sammanslagning in i grenen <namn>. Syntaxen och de alternativ som stöds är samma som för git merge, men alternativvärden som innehåller blanksteg stöds för närvarande inte.
Allt ovanför denna rad i detta avsnitt ingår inte från dokumentationen för git-config(1). Innehållet nedan är samma som finns där.
merge.conflictStyle
Anger stilen som konfliktande hunks skrivs ut med i arbetskatalogens filer vid sammanslagning. Standard är merge, vilket visar en <<<<<<<-markör, ändringar från ena sidan, en =======-markör, ändringar från den andra sidan och sedan en >>>>>>>-markör. Den alternativa stilen diff3 lägger till en |||||||-markör och originaltexten före =======-markören. Stilen merge tenderar att ge mindre konfliktområden än diff3, både eftersom originaltexten utelämnas och eftersom rader som matchar på båda sidorna dras ut ur konfliktområdet. En annan alternativ stil, zdiff3, liknar diff3 men tar bort matchande rader på de två sidorna från konfliktområdet när dessa matchande rader finns nära konfliktområdets början eller slut.
merge.defaultToUpstream
Om merge anropas utan commit-argument slås de upstream-grenar samman som är konfigurerade för den aktuella grenen, med hjälp av deras senast observerade värden i remote-tracking-grenarna. Värdena i branch.<aktuell-gren>.merge, som namnger grenarna hos den remote som anges av branch.<aktuell-gren>.remote, används och mappas sedan via remote.<remote>.fetch till motsvarande remote-tracking-grenar. Spetsarna på dessa tracking-grenar slås samman. Standard är true.
merge.ff
Som standard skapar Git ingen extra merge-commit när en commit som är ättling till den aktuella commit:en slås samman. I stället fast-forwardas spetsen på den aktuella grenen. När variabeln sätts till false säger den åt Git att skapa en extra merge-commit i detta fall, motsvarande --no-ff på kommandoraden. När den sätts till only tillåts endast fast-forward-sammanslagningar, motsvarande --ff-only.
merge.verifySignatures
Om värdet är sant motsvarar detta kommandoradsalternativet --verify-signatures. Se git-merge(1) för detaljer.
merge.branchdesc
Utöver grennamn fylls loggmeddelandet med grenbeskrivningstexten som är kopplad till dem. Standard är false.
merge.log
Utöver grennamn fylls loggmeddelandet med högst det angivna antalet enradsbeskrivningar från de faktiska commit:ar som slås samman. Standard är false, och true är en synonym för 20.
merge.suppressDest
Genom att lägga till ett globmönster som matchar namn på integrationsgrenar i denna flervärdeskonfigurationsvariabel kan standardmeddelandet för sammanslagningar in i dessa integrationsgrenar utelämna ”into <grennamn>” från titeln.
Ett element med tomt värde kan användas för att rensa listan av globmönster som samlats från tidigare konfigurationsposter. När ingen merge.suppressDest-variabel är definierad används standardvärdet master för bakåtkompatibilitet.
merge.renameLimit
Antalet filer som ska beaktas i den uttömmande delen av namnbytesdetekteringen vid sammanslagning. Om det inte anges används värdet från diff.renameLimit. Om varken merge.renameLimit eller diff.renameLimit anges är standarden för närvarande 7000. Inställningen har ingen effekt om namnbytesdetektering är avstängd.
merge.renames
Anger om Git upptäcker namnbyten. Om värdet är false inaktiveras namnbytesdetektering. Om värdet är true aktiveras grundläggande namnbytesdetektering. Standard är värdet från diff.renames.
merge.directoryRenames
Anger om Git upptäcker katalognamnbyten. Detta påverkar vad som händer vid sammanslagning med nya filer som lagts till i en katalog på ena sidan av historiken när katalogen döpts om på den andra sidan. Möjliga värden är:
false
Katalognamnbytesdetektering är inaktiverad, vilket innebär att sådana nya filer lämnas kvar i den gamla katalogen.
true
Katalognamnbytesdetektering är aktiverad, vilket innebär att sådana nya filer flyttas till den nya katalogen.
conflict
En konflikt rapporteras för sådana sökvägar.
Om merge.renames är false ignoreras merge.directoryRenames och behandlas som false. Standard är conflict.
merge.renormalize
Säger åt Git att den kanoniska representationen av filer i arkivet har ändrats över tid, till exempel om äldre commit:ar lagrar textfiler med CRLF-radslut men nyare använder LF-radslut. I ett sådant arkiv kan Git, för varje fil där en trevägssammanslagning behövs, konvertera data som lagrats i commit:ar till en kanonisk form innan sammanslagningen görs för att minska onödiga konflikter. Se avsnittet om sammanslagning av grenar med olika checkin-/checkout-attribut i gitattributes(5).
merge.stat
Anger vad, om något, som ska skrivas mellan ORIG_HEAD och merge-resultatet i slutet av sammanslagningen. Möjliga värden är:
false
Visa ingenting.
true
Visa git diff --diffstat --summary ORIG_HEAD.
compact
Visa git diff --compact-summary ORIG_HEAD.
Okända värden, till exempel värden som kan läggas till i framtida Git-versioner, tolkas som true i stället för att ge fel. Standard är true.
merge.autoStash
När värdet är true skapas automatiskt en tillfällig stash-post innan åtgärden startar och den appliceras efter att åtgärden avslutats. Det gör att du kan köra merge i en arbetskatalog med ändringar. Använd med försiktighet: den slutliga stash-appliceringen efter en lyckad sammanslagning kan leda till icke-triviala konflikter. Alternativet kan upphävas av --no-autostash och --autostash för git-merge(1). Standard är false.
merge.tool
Styr vilket merge-verktyg som används av git-mergetool(1). Listan nedan visar giltiga inbyggda värden. Alla andra värden behandlas som ett eget merge-verktyg och kräver att motsvarande variabel mergetool.<verktyg>.cmd är definierad.
merge.guitool
Styr vilket merge-verktyg som används av git-mergetool(1) när flaggan -g eller --gui anges. Listan nedan visar giltiga inbyggda värden. Alla andra värden behandlas som ett eget merge-verktyg och kräver att motsvarande mergetool.<guitool>.cmd är definierad.
araxis
Använd Araxis Merge, kräver grafisk session.
bc, bc3, bc4
Använd Beyond Compare, kräver grafisk session.
codecompare
Använd Code Compare, kräver grafisk session.
deltawalker
Använd DeltaWalker, kräver grafisk session.
diffmerge
Använd DiffMerge, kräver grafisk session.
diffuse
Använd Diffuse, kräver grafisk session.
ecmerge
Använd ECMerge, kräver grafisk session.
emerge
Använd Emacs Emerge.
examdiff
Använd ExamDiff Pro, kräver grafisk session.
guiffy
Använd Guiffys diffverktyg, kräver grafisk session.
gvimdiff
Använd gVim, kräver grafisk session, med anpassad layout. Se avsnittet om backend-specifika tips i git help mergetool.
gvimdiff1
Använd gVim, kräver grafisk session, med två paneler: LOCAL och REMOTE.
gvimdiff2
Använd gVim, kräver grafisk session, med tre paneler: LOCAL, MERGED och REMOTE.
gvimdiff3
Använd gVim, kräver grafisk session, där endast MERGED-filen visas.
kdiff3
Använd KDiff3, kräver grafisk session.
meld
Använd Meld, kräver grafisk session, med valfri automatisk merge. Se konfigurationsavsnittet i git help mergetool.
nvimdiff
Använd Neovim med anpassad layout. Se avsnittet om backend-specifika tips i git help mergetool.
nvimdiff1
Använd Neovim med två paneler: LOCAL och REMOTE.
nvimdiff2
Använd Neovim med tre paneler: LOCAL, MERGED och REMOTE.
nvimdiff3
Använd Neovim där endast MERGED-filen visas.
opendiff
Använd FileMerge, kräver grafisk session.
p4merge
Använd HelixCore P4Merge, kräver grafisk session.
smerge
Använd Sublime Merge, kräver grafisk session.
tkdiff
Använd TkDiff, kräver grafisk session.
tortoisemerge
Använd TortoiseMerge, kräver grafisk session.
vimdiff
Använd Vim med anpassad layout. Se avsnittet om backend-specifika tips i git help mergetool.
vimdiff1
Använd Vim med två paneler: LOCAL och REMOTE.
vimdiff2
Använd Vim med tre paneler: LOCAL, MERGED och REMOTE.
vimdiff3
Använd Vim där endast MERGED-filen visas.
vscode
Använd Visual Studio Code, kräver grafisk session.
winmerge
Använd WinMerge, kräver grafisk session.
xxdiff
Använd xxdiff, kräver grafisk session.
merge.verbosity
Styr hur mycket utdata som visas av den rekursiva merge-strategin. Nivå 0 visar inget förutom ett slutligt felmeddelande om konflikter upptäcktes. Nivå 1 visar endast konflikter, nivå 2 visar konflikter och filändringar. Nivå 5 och högre visar felsökningsinformation. Standard är nivå 2. Kan åsidosättas med miljövariabeln GIT_MERGE_VERBOSITY.
merge.<driver>.name
Definierar ett läsbart namn för en egen låg-nivå-merge-driver. Se gitattributes(5) för detaljer.
merge.<driver>.driver
Definierar kommandot som implementerar en egen låg-nivå-merge-driver. Se gitattributes(5) för detaljer.
merge.<driver>.recursive
Namnger en låg-nivå-merge-driver som ska användas när en intern sammanslagning mellan gemensamma anfäder utförs. Se gitattributes(5) för detaljer.
Se även
git-fmt-merge-msg(1), git-pull(1), gitattributes(5), git-reset(1), git-diff(1), git-ls-files(1), git-add(1), git-rm(1), git-mergetool(1)
Git
Del av sviten git(1).
Kolofon
Denna sida ingår i projektet git (Git distribuerat versionshanteringssystem). Information om projektet finns på http://git-scm.com/. Om du vill rapportera ett fel i manualsidan, se http://git-scm.com/community. Denna sida hämtades från projektets uppströms Git-arkiv https://github.com/git/git.git den 24 maj 2026. Vid den tidpunkten var datumet för den senaste commit som hittades i arkivet den 22 maj 2026.
Om du hittar renderingsproblem i denna HTML-version av sidan, känner till en bättre eller mer uppdaterad källa, eller har rättelser eller förbättringar till informationen i denna kolofon, skicka e-post till man-pages@man7.org.
Git 2.54.0.254.g6a4418 2026-05-22 GIT-MERGE(1)
Sidor som hänvisar till denna sida
git(1), git-branch(1), git-cherry-pick(1), git-commit(1), git-config(1), git-diff(1), git-fmt-merge-msg(1), git-merge(1), git-merge-base(1), git-merge-tree(1), git-pull(1), git-revert(1), stg-repair(1), githooks(5), giteveryday(7), gitglossary(7), gitworkflows(7).