Git

git-merge last updated in 2.53.0

NAMN

git-merge - Join two or more development histories together

SYNOPSIS

git merge [-n] [--stat] [--compact-summary] [--no-commit] [--squash] [--[no-]edit]
	[--no-verify] [-s <strategi>] [-X <strategi-flaggor>] [-S[<nyckelid>]]
	[--[no-]allow-unrelated-histories]
	[--[no-]rerere-autoupdate] [-m <msg>] [-F <fil>]
	[--into-name <gren>] [<incheckning>…]
git merge (--continue | --abort | --quit)

BESKRIVNING

Inkorporerar ändringar från de namngivna incheckningar (sedan deras historik avvek från den aktuella grenen) i den aktuella grenen. Detta kommando används av git pull för att införliva ändringar från ett annat arkiv och kan användas manuellt för att sammanfoga ändringar från en gren till en annan.

Anta att följande historik finns och att den aktuella grenen är master:

          A---B---C ämne
         /
    D---E---F---G master

Sedan kommer git merge ämne att spela upp ändringarna som gjorts på grenen ämne sedan den avvek från master (dvs. E) fram till dess nuvarande commit (C) ovanpå master, och registrera resultatet i en ny incheckning tillsammans med namnen på de två överordnade incheckningar och ett loggmeddelande från användaren som beskriver ändringarna. Innan operationen sätts ORIG_HEAD till toppen av den nuvarande grenen (G).

          A---B---C ämne
         /         \
    D---E---F---G---H master

En sammanslagning stoppas om det finns en konflikt som inte kan lösas automatiskt eller om --no-commit angavs när sammanslagningen initierades. Vid den tidpunkten kan du köra git merge --abort eller git merge --continue.

git merge --abort avbryter sammanslagningsprocessen och försöker rekonstruera tillståndet före sammanslagningen. Om det dock fanns obekräftade ändringar när sammanslagningen startade (och särskilt om dessa ändringar modifierades ytterligare efter att sammanslagningen startades), kommer git merge --abort i vissa fall inte att kunna rekonstruera de ursprungliga (före sammanslagningen) ändringarna. Därför:

Warning

Att köra git merge med icke-triviala oincheckade ändringar avråds: även om det är möjligt kan det försätta dig i ett tillstånd som är svårt att ta sig ur i händelse av en konflikt.

ALTERNATIV

--commit
--no-commit: Utför sammanslagningen och spara resultatet. Det här alternativet kan användas för att åsidosätta --no-commit.

Med --no-commit utför du sammanslagnings-funktionen och stoppar den precis innan du skapar en sammanslagnings-incheckning, för att ge användaren en chans att granska och ytterligare justera sammanslagnings-resultatet innan den checkar in.

Observera att snabbspolningsuppdateringar inte skapar en sammanslagins-incheckning och därför finns det inget sätt att stoppa dessa sammanslagningar med --no-commit. Om du vill se till att din gren inte ändras eller uppdateras av sammanslagings-kommandot, använd --no-ff med --no-commit.
--edit
-e
--no-edit: Anropa en editor innan den mekaniska sammanfogningen genomförs för att ytterligare redigera det automatiskt genererade sammanfogningsmeddelandet, så att användaren kan förklara och motivera sammanfogningen. Alternativet --no-edit kan användas för att acceptera det automatiskt genererade meddelandet (detta avråds generellt). Alternativet --edit (eller -e) är fortfarande användbart om du ger ett utkastmeddelande med alternativet -m från kommandoraden och vill redigera det i redigeraren.

Äldre skript kan bero på det historiska beteendet att inte tillåta användaren att redigera sammanslagningsloggmeddelandet. De kommer att se en editor öppen när de kör git merge. För att göra det enklare att anpassa sådana skript till det uppdaterade beteendet kan miljövariabeln GIT_MERGE_AUTOEDIT sättas till no i början av dem.
--cleanup=<läge>: Det här alternativet avgör hur sammanslagningsmeddelandet ska rensas innan det incheckas. Se git-commit[1] för mer information. Om <läge> dessutom ges värdet scissors, kommer scissors att läggas till i MERGE_MSG innan de skickas vidare till inchecknings-maskineriet i händelse av en sammanslagningskonflikt.
--ff
--no-ff
--ff-only: Anger hur en sammanslagning hanteras när den sammanslagna historiken redan är en underordnad del av den aktuella historiken. --ff är standardinställningen om inte en kommenterad (och eventuellt signerad) tagg som inte lagras på sin naturliga plats i refs/tags/-hierarkin sammanfogas, i vilket fall --no-ff antas.

Med --ff, lös när det är möjligt sammanslagningen som en snabbspolning framåt (uppdatera endast grenpekaren så att den matchar den sammanslagna grenen; skapa inte en merge-commit). När det inte är möjligt (när den sammanslagna historiken inte är en underordnad del av den aktuella historiken), skapa en sammanslagings-incheckning.

Med --no-ff, skapa en sammanslagings-incheckning i alla fall, även när merge istället skulle kunna lösas som en snabbspolning framåt.

Med --ff-only, lös sammanslagningen som en snabbspolning framåt när det är möjligt. När det inte är möjligt, vägra sammanslagningen och avsluta med en status som inte är noll.
-S[<nyckel-id>]
--gpg-sign[=<nyckel-id>]
--no-gpg-sign: GPG-signera den resulterande sammanslagningsincheckningen. Argumentet <nyckel-id> är valfritt och har som standard incheckare-identiteten; om det anges måste det fästas vid alternativet utan mellanslag. --no-gpg-sign är användbart för att negligera både konfigurationsvariabeln commit.gpgSign och den tidigare --gpg-sign.
--log[=<n>]
--no-log: Förutom grennamn, fyll i loggmeddelandet med enradsbeskrivningar från högst <n> faktiska incheckningar som sammanfogas. Se även git-fmt-merge-msg[1].

Med --no-log listas inte enradsbeskrivningar från de faktiska incheckningar som sammanfogas.
--signoff
--no-signoff: Add a Signed-off-by trailer by the committer at the end of the commit log message. The meaning of a signoff depends on the project to which you’re committing. For example, it may certify that the committer has the rights to submit the work under the project’s license or agrees to some contributor representation, such as a Developer Certificate of Origin. (See https://developercertificate.org for the one used by the Linux kernel and Git projects.) Consult the documentation or leadership of the project to which you’re contributing to understand how the signoffs are used in that project.

Alternativet --no-signoff kan användas för att upphäva ett tidigare --signoff-alternativ på kommandoraden.

Git har inte (och kommer inte ha) en konfigurationsvariabel för att aktivera kommandoradsalternativet --signoff som standard; se commit.signoff-posten i gitfaq[7] för mer information.

--stat
-n
--no-stat: Visa en diffstat i slutet av sammanslagningen. Diffstat styrs också av konfigurationsalternativet merge.stat.

Med -n eller --no-stat visas ingen diffstat i slutet av sammanslagningen.
--compact-summary: Visa en kompakt sammanfattning när sammanslagningen är färdig.
--squash
--no-squash: Skapa arbetsträdet och indextillståndet som om en riktig sammanslagning hade skett (förutom sammanslagningsinformationen), men gör inte en faktisk incheckning, flytta inte HEAD eller registrera $GIT_DIR/MERGE_HEAD (för att få nästa git commit-kommando att skapa en sammanslagnings-incheckning). Detta låter dig skapa en enda incheckning ovanpå den aktuella grenen vars effekt är densamma som att sammanfoga en annan gren (eller fler i fallet med en bläckfisk).

Med --no-squash utförs sammanslagningen och chacka-in resultatet. Detta alternativ kan användas för att åsidosätta --squash.

Med --squash är --commit inte tillåtet och kommer att misslyckas.
--verify
--no-verify: Som standard, körs pre-merge- och commit-msg-krokarna. När --no-verify anges, kringgås dessa. Se även githooks[5].
-s <strategi>
--strategy=<strategi>: Använd den givna sammanslagningsstrategin; kan anges mer än en gång för att ange dem i den ordning de ska provas. Om det inte finns något -s-alternativ används en inbyggd lista med strategier istället (ort vid sammanslagning av en enskild rubrik, octopus annars).
-X <alternativ>
--strategy-option=<alternativ>: Skicka det specifika alternativet för sammanslagningsstrategin vidare till sammanslagningsstrategin.
--verify-signatures
--no-verify-signatures: Verifiera att tip incheckningen för sidgrenen som sammanfogas är signerad med en giltig nyckel, d.v.s. en nyckel som har en giltig uid: i standardförtroendemodellen betyder detta att signeringsnyckeln har signerats av en betrodd nyckel. Om top incheckningen för sidgrenen inte är signerad med en giltig nyckel avbryts sammanfogningen.
--summary
--no-summary: Synonymer till --stat och --no-stat; dessa är föråldrade och kommer att tas bort i framtiden.
-q
--quiet: Arbeta tyst. Innebär --no-progress.
-v
--verbose: Var utförlig.
--progress
--no-progress: Aktivera/avaktivera förloppet explicit. Om ingetdera anges visas förloppet om standardfelet är kopplat till en terminal. Observera att inte alla sammanslagningsstrategier stöder förloppsrapportering.
--autostash
--no-autostash: Skapa automatiskt en tillfällig gömma-post innan operationen börjar, registrera den i referensen MERGE_AUTOSTASH och tillämpa den efter att operationen är avslutad. Det betyder att du kan köra operationen på ett smutsigt arbetsträd. Använd dock försiktigt: den slutliga gömma-applikationen efter en lyckad sammanslagning kan resultera i icke-triviala konflikter.
--allow-unrelated-histories: Som standard vägrar git merge-kommandot att slå samman historiker som inte delar en gemensam förfader. Det här alternativet kan användas för att åsidosätta denna säkerhetsåtgärd när man slår samman historiker för två projekt som startade sina liv oberoende av varandra. Eftersom det är ett mycket sällsynt fall finns ingen konfigurationsvariabel för att aktivera detta som standard, och kommer inte att läggas till.

-m <medd>: Ange inchecknings-meddelandet som ska användas för sammanslagings-incheckning (om en sådan skapas).

Om --log anges, kommer en kort logg över de incheckningar som sammanfogas att läggas till i det angivna meddelandet.

Kommandot git fmt-merge-msg kan användas för att ge en bra standard för automatiserade git merge-anrop. Det automatiserade meddelandet kan innehålla grenbeskrivningen.
--into-name <gren>: Förbered standardmeddelandet för sammanslagning som om man sammanfogar till grenen <gren>, istället för namnet på den riktiga gren som sammanslagningen görs till.
-F <fil>
--file=<fil>: Läs inchecknings-meddelandet som ska användas för sammanslagings-incheckning (om en sådan skapas).

Om --log anges, kommer en kort logg över de incheckningar som sammanfogas att läggas till i det angivna meddelandet.
--rerere-autoupdate
--no-rerere-autoupdate: Efter att rerere-mekanismen återanvänder en inspelad lösning på den aktuella konflikten för att uppdatera filerna i arbetskatalogen, tillåt den även att uppdatera indexet med resultatet av lösningen. --no-rerere-autoupdate är ett bra sätt att dubbelkolla vad rerere gjorde och upptäcka potentiella felaktiga sammanfogningar, innan resultatet sparas i indexet med ett separat git add.

--overwrite-ignore
--no-overwrite-ignore: Skriv tyst över ignorerade filer från sammanslagningsresultatet. Detta är standardbeteendet. Använd --no-overwrite-ignore för att avbryta.
--abort: Avbryt den aktuella konfliktlösningsprocessen och försök att rekonstruera tillståndet före sammanslagningen. Om en autostash-post finns, tillämpa den på arbetsträdet.

Om det fanns oincheckade arbetsträdsändringar när sammanslagningen startade, kommer git merge --abort i vissa fall inte att kunna rekonstruera dessa ändringar. Det rekommenderas därför att alltid inchecka eller gömma dina ändringar innan du kör git merge.

git merge --abort är ekvivalent med git reset --merge när MERGE_HEAD finns, såvida inte MERGE_AUTOSTASH också finns, i vilket fall git merge --abort tillämpar stash-posten på arbetsträdet medan git reset --merge sparar de gömmda ändringarna i stash-listan.
--quit: Glöm den pågående sammanslagningen. Lämna indexet och arbetsträdet som de är. Om MERGE_AUTOSTASH finns, kommer stash-posten att sparas i stash-listan.
--continue: Efter att en git merge har stoppats på grund av konflikter kan du avsluta sammanslagningen genom att köra git merge --continue (se avsnittet "HUR MAN LÖSER KONFLIKTER" nedan).
<incheckning>...: Commits, vanligtvis andra grenhuvuden, för att slås samman med vår gren. Om du anger mer än en incheckning skapas en sammanslagning med mer än två föräldrar (kärleksfullt kallad en bläckfisk-sammanslagning).

Om ingen commit ges från kommandoraden, sammanfoga de fjärrspårningsgrenar som den aktuella grenen är konfigurerad att använda som sin uppström. Se även konfigurationsavsnittet på den här manualsidan.

När FETCH_HEAD (och ingen annan incheckning) anges, slås grenarna som registrerats i .git/FETCH_HEAD-filen genom föregående anrop av git fetch för sammanslagning samman med den aktuella grenen.

KONTROLLER FÖRE SAMMANSLAGNING

Innan du tillämpar externa ändringar bör du få ditt eget arbete i gott skick och checka-in det lokalt, så att det inte blir förstört om det uppstår konflikter. Se även git-stash[1]. git pull och git merge kommer att stoppas utan att göra någonting när lokala oincheckade ändringar överlappar med filer som git pull/git merge kan behöva uppdatera.

För att undvika att orelaterade ändringar registreras i sammanslagings-incheckningen, kommer git pull och git merge också att avbrytas om det finns några ändringar registrerade i indexet i förhållande till HEAD-commiten. (Särskilda snäva undantag från denna regel kan finnas beroende på vilken sammanslagings-strategi som används, men generellt måste indexet matcha HEAD.)

Om alla namngivna incheckningar redan är föregångare till HEAD, kommer git merge att avslutas tidigt med meddelandet "Redan uppdaterad".

SNABBSPOLNING FRAMÅT SAMMANSLAGNING

Ofta är den aktuella grenhuvudet en förfader till den namngivna incheckningen. Detta är det vanligaste fallet, särskilt när det anropas från git pull: du spårar ett uppströms arkiv, du har inte incheckat några lokala ändringar och nu vill du uppdatera till en nyare uppströmsversion. I det här fallet behövs inte en ny incheckning för att lagra den kombinerade historiken; istället uppdateras HEAD (tillsammans med indexet) för att peka på den namngivna incheckningen, utan att skapa en extra sammanslagings-incheckning.

Detta beteende kan undertryckas med alternativet --no-ff.

SANN SAMMANSLAGNING

Förutom i en snabbsamlare (se ovan) måste grenarna som ska slås samman knytas samman av en sammanslagnings-incheckning som har båda som sina föräldrar.

En sammanfogad version som avstämmer ändringarna från alla grenar som ska sammanfogas implementeras, och din HEAD, index och arbetsträd uppdateras till den. Det är möjligt att ha ändringar i arbetsträdet så länge de inte överlappar varandra; uppdateringen kommer att bevara dem.

När det inte är uppenbart hur ändringarna ska avstämmas händer följande:

Pekaren HEAD förblir densamma.
Referensen MERGE_HEAD är inställd att peka på den andra grenhuvudet.
Sökvägar som sammanfogats korrekt uppdateras både i indexfilen och i ditt arbetskatalog.
För motstridiga sökvägar registrerar indexfilen upp till tre versioner: steg 1 lagrar versionen från den gemensamma förfadern, steg 2 från HEAD och steg 3 från MERGE_HEAD (du kan inspektera stegen med git ls-files -u). Arbetskatalogen innehåller resultatet av sammanslagningsoperationen; dvs. 3-vägs sammanslagningsresultat med välkända konfliktmarkörer <<< === >>>.
En referens med namnet AUTO_MERGE skrivs, som pekar på ett träd som motsvarar det aktuella innehållet i arbetsträdet (inklusive konfliktmarkörer för textkonflikter). Observera att denna referens endast skrivs när sammanslagningsstrategin ort används (standard).
Inga andra ändringar görs. I synnerhet kommer de lokala ändringar du hade innan du började sammanfoga att förbli desamma och indexposterna för dem förblir som de var, dvs. matchar HEAD.

Om du försökte en sammanslagning som resulterade i komplexa konflikter och vill börja om, kan du återställa med git merge --abort.

SAMMANSLAGNING AV TAGG

När man sammanfogar en kommenterad (och eventuellt signerad) tagg skapar Git alltid en sammanslagings-incheckning även om en snabbspolning framåt är möjlig, och inchecknings-meddelandemallen förbereds med taggmeddelandet. Dessutom, om taggen är signerad, rapporteras signaturkontrollen som en kommentar i meddelandemallen. Se även git-tag[1].

När du bara vill integrera med det arbete som leder till den incheckning som råkar vara taggad, t.ex. synkronisera med en uppströms utgivningspunkt, kanske du inte vill göra en onödig sammanslagings-incheckning.

I ett sådant fall, kan du "packa upp" taggen själv innan du skickar den till git merge, eller skicka --ff-only när du inte har något eget arbete. t.ex.

git fetch origin
git merge v1.2.3^0
git merge --ff-only v1.2.3

HUR KONFLIKTER PRESENTERAS

Under en sammanslagning uppdateras arbetskatalog för att återspegla resultatet av sammanslagningen. Bland de ändringar som gjorts i den gemensamma förfaderns version införlivas icke-överlappande ändringar (det vill säga att du ändrade ett område i filen medan den andra sidan lämnade det området intakt, eller vice versa) ordagrant i det slutliga resultatet. När båda sidor har gjort ändringar i samma område kan Git dock inte slumpmässigt välja den ena sidan framför den andra, och ber dig att lösa det genom att lämna vad båda sidor gjorde i det området.

Som standard, använder Git samma stil som den som används av "merge"-programmet från RCS-sviten för att presentera en sådan konfliktfylld bit, så här:

Här är rader som antingen är oförändrade från den gemensamma
förfadern, eller är rent upplösta eftersom bara en sida har ändrats,
eller är rent upplösta eftersom båda sidor har ändrats på samma sätt.
<<<<<<<< din:prov.txt
Konfliktlösning är svårt;
låt oss gå och handla.
=======
Git gör konfliktlösning enkelt.
>>>>>>>> deras:prov.txt
Och här är en annan rad som är rent upplöst eller omodifierad.

Området där ett par motstridiga ändringar inträffade markeras med markörerna <<<<<<<<, ======= och >>>>>>>. Delen före ======= är vanligtvis din sida, och delen efteråt är vanligtvis deras sida.

Standardformatet visar inte vad originalet sa i konfliktområdet. Du kan inte se hur många rader som har tagits bort och ersatts med Barbies kommentar på din sida. Det enda du kan se är att din sida vill säga att det är svårt och att du hellre vill handla, medan den andra sidan vill påstå att det är lätt.

En alternativ stil kan användas genom att ställa in konfigurationsvariabeln merge.conflictStyle till antingen diff3 eller zdiff3. I diff3-stilen kan konflikten ovan se ut så här:

Här är rader som antingen är oförändrade från den gemensamma
förfadern, eller rent lösta eftersom bara en sida ändrades,
<<<<<<<< din:prov.txt
eller rent lösta eftersom båda sidor ändrades på samma sätt.
Konfliktlösning är svårt;
låt oss gå och handla.
||||||| bas:prov.txt
eller rent lösta eftersom båda sidor ändrades identiskt.
Konfliktlösning är svårt.
=======
eller rent lösta eftersom båda sidor ändrades på samma sätt.
Git gör konfliktlösning enkel.
>>>>>>> deras:prov.txt
Och här är en annan rad som är rent löst eller omodifierad.

i zdiff3-stil kan det se ut så här:

Här är rader som antingen är oförändrade från den gemensamma
förfadern, eller rent lösta eftersom bara en sida ändrades,
eller rent lösta eftersom båda sidor ändrades på samma sätt.
<<<<<<<< din:prov.txt
Konfliktlösning är svårt;
låt oss gå och shoppa.
||||||| bas:prov.txt
eller rent lösta eftersom båda sidor ändrades identiskt.
Konfliktlösning är svårt.
=======
Git gör konfliktlösning enkel.
>>>>>>>> deras:prov.txt
Och här är en annan rad som är rent löst eller omodifierad.

Förutom markörerna <<<<<<<, ======= och >>>>>>> används ytterligare en markör |||||||| som följs av originaltexten. Du kan se att originalet bara konstaterade ett faktum, och din sida gav helt enkelt efter för det påståendet och upp, medan den andra sidan försökte ha en mer positiv attityd. Ibland kan du komma fram till en bättre lösning genom att titta på originalet.

HUR MAN LÖSER KONFLIKTER

Efter att ha sett en konflikt kan du göra två saker:

Bestäm dig för att inte sammanfoga. De enda rensningarna du behöver göra är att återställa indexfilen till HEAD-incheckning för att vända 2. och att rensa upp fungerande trädändringar gjorda av 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 git add dem till indexet. Använd git commit eller git merge --continue för att avsluta affären. Det senare kommandot kontrollerar om det pågår en (avbruten) sammanslagning innan git commit anropas.

Du kan bearbeta konflikten med ett antal verktyg:

Använd ett mergetool. git mergetool för att starta ett grafiskt mergetool som kommer att arbeta genom sammanslagingsprocessen tillsammans med dig.
Titta på skillnaderna. 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 har gjort hittills för att lösa textkonflikter.
Titta på skillnaderna från varje gren. git log --merge -p <sökväg> visar först skillnaderna för HEAD-versionen och sedan MERGE_HEAD-versionen.
Titta på originalversionerna. git show :1:filnamn visar den gemensamma förfadern, git show :2:filnamn visar HEAD-versionen och git show :3:filnamn visar MERGE_HEAD-versionen.

EXEMPEL

Sammanfoga grenarna fixes och förbättringar ovanpå den aktuella grenen, vilket skapar en bläckfisk-sammanslagning:
```
$ git merge fixar förbättringar
```
Sammanfoga grenen obsolete med den aktuella grenen med hjälp av sammanfogningsstrategin ours:
```
$ git merge -s ours obsolete
```
Sammanfoga grenen maint med den aktuella grenen, men gör inte en ny incheckning automatiskt:
```
$ git merge --no-commit maint
```
Detta kan användas när du vill inkludera ytterligare ändringar i sammanslagningen, eller vill skriva ditt eget sammanslagningsmeddelande.

Du bör avstå från att missbruka det här alternativet för att smyga in väsentliga ändringar i en sammanslagnings-incheckningen. Små korrigeringar som att bumpa utgåva/versionsnamn skulle vara acceptabla.

SAMMANSLAGNINGSSTRATEGIER

Sammanfogningsmekanismen (kommandona git merge och git pull) gör det möjligt att välja bakända-sammanfogningsstrategier med alternativet -s. Vissa strategier kan också ta sina egna alternativ, vilka kan skickas genom att ge -X<alternativ>-argument till git merge och/eller git pull.

ort

Detta är standardstrategin för sammanslagning när man drar in ("pulla") eller sammanfogar en gren. Denna strategi kan bara lösa två huvuden med hjälp av en 3-vägs sammanslagningsalgoritm. När det finns mer än en gemensam förfader som kan användas för 3-vägs sammanslagning skapas ett sammanslaget träd av de gemensamma förfäderna och används som referensträd för 3-vägs sammanslagningen. Detta har rapporterats resultera i färre sammanslagningskonflikter utan att orsaka felsammanslagningar, enligt tester gjorda på faktiska sammanslagningscommits hämtade från Linux 2.6-kärnans utvecklingshistorik. Dessutom kan denna strategi upptäcka och hantera sammanslagningar som involverar namnbyten. Den använder inte upptäckta kopior. Namnet på denna algoritm är en akronym ("Ostensibly Recursive’s Twin") och kommer från det faktum att den skrevs som en ersättning för den tidigare standardalgoritmen, "rekursiv".

I det fall där sökvägen är en undermodul, och undermodul-incheckningen som används på ena sidan av sammanslagnings-sekvensen är en underordnad undermodul-incheckning som används på den andra sidan av merge-sekvensen, försöker Git att snabbspola fram till underordnad. Annars kommer Git att behandla detta fall som en konflikt och föreslå som en lösning en undermodul-incheckningen som är underordnad de konflikterande, om en sådan finns.

ort-strategin kan ha följande alternativ:

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 in the merge result. For a binary file, the entire contents are taken from our side.

Detta bör inte förväxlas med ours sammanslagningsstrategi, som inte ens tittar på vad det andra trädet innehåller alls. Den kasserar allt som det andra trädet gjorde och deklarerar att vår historia innehåller allt som hände i det.

theirs

Detta är motsatsen till ours; observera att det, till skillnad från ours, inte finns någon theirs-sammanslagningsstrategi att förväxla detta sammanslagningsalternativ med.

ignore-space-change

ignore-all-space

ignore-space-at-eol

ignore-cr-at-eol

Behandlar rader med den angivna typen av blankteckenändring som oförändrade för en trevägssammanslagning. Ändringar av blanktecken blandade med andra ändringar på en rad ignoreras inte. Se även git-diff[1] -b, -w, --ignore-space-at-eol och --ignore-cr-at-eol.

Om deras version bara introducerar ändringar av blanksteg på en rad används vår version;
Om vår version introducerar ändringar i blanksteg men deras version inkluderar en väsentlig ändring, används deras version;
Annars fortsätter sammanslagningen på vanligt sätt.

renormalize

Detta kör en virtuell utcheckning och incheckning av alla tre stegen i alla filer som behöver en trevägssammanslagning. Det här alternativet är avsett att användas vid sammanslagning av grenar med olika rena filter eller normaliseringsregler för radslut. Se "Sammanfoga grenar med olika inchecknings-/utcheckningsattribut" i gitattributes[5] för mer information.

no-renormalize

Inaktiverar alternativet renormalize. Detta åsidosätter konfigurationsvariabeln merge.renormalize.

find-renames[=<n>]

Aktivera namnbytesdetektering, och ställ in likhetströskeln om du vill. Detta är standardinställningen. Detta åsidosätter konfigurationsvariabeln merge.renames. Se även git-diff[1] --find-renames.

rename-threshold=<n>

Föråldrad synonym för find-renames=<n>.

no-renames

Stäng av namnbytesdetektering. Detta åsidosätter konfigurationsvariabeln merge.renames. Se även git-diff[1] --no-renames.

histogram

Föråldrad synonym för diff-algoritm=histogram.

patience

Föråldrad synonym för diff-algoritm=patience.

diff-algorithm=(histogram|minimal|myers|patience)

Använd en annan diff-algoritm vid sammanfogning, vilket kan bidra till att undvika felsammanfogningar som uppstår på grund av oviktiga matchande rader (som klammerparenteser från olika funktioner). Se även git-diff[1] --diff-algorithm. Observera att ort som standard har diff-algorithm=histogram, medan vanliga diffs för närvarande har konfigurationsinställningen diff.algorithm.

subtree[=<sökväg>]

Det här alternativet är en mer avancerad form av "underträdsstrategi" (subtree), där strategin gissar hur två träd måste flyttas för att matcha varandra vid sammanslagning. Istället prefixeras den angivna sökvägen (eller tas bort från början) för att få formen på de två träden att matcha.

recursive

Detta är nu en synonym för ort. Det var en alternativ implementering fram till v2.49.0, men omdirigerades till att betyda ort i v2.50.0. Den tidigare rekursiva strategin var standardstrategin för att lösa två huvuden från Git v0.99.9k till v2.33.0.

resolve

Detta kan bara lösa två huvuden (dvs. den aktuella grenen och en annan gren du hämtade från) med hjälp av en 3-vägs merge-algoritm. Den försöker noggrant upptäcka korsvisa sammanslagings-tvetydigheter. Den hanterar inte namnbyten.

octopus

Detta löser fall med fler än två huvuden, men vägrar att göra en komplex sammanslagning som kräver manuell lösning. Det är främst avsett att användas för att paketera ämnesgrenhuvuden. Detta är standardsammanslagningsstrategin när man drar in ("pullar") eller sammanfogar mer än en gren.

ours

Detta kan bara lösa två huvuden (dvs. den aktuella grenen och en annan gren du hämtade från) med hjälp av en 3-vägs sammanslagnings-algoritm. Den försöker noggrant upptäcka korsvisa sammanslagnings-tvetydigheter. Den hanterar inte namnbyten.

subtree

Detta är en modifierad ort-strategi. När träd A och B sammanfogas, och B motsvarar ett underträd till A, justeras B först för att matcha trädstrukturen för A, istället för att läsa träden på samma nivå. Denna justering görs också på det gemensamma förfader-trädet.

Med strategier som använder 3-vägssammanslagning (inklusive standardvärdet ort), om en ändring görs på båda grenarna, men senare ångrad på en av grenarna, kommer den ändringen att finnas i det sammanslagna resultatet; vissa personer tycker att detta beteende är förvirrande. Det inträffar eftersom endast huvuden och sammanslagningsbasen beaktas när en sammanslagning utförs, inte de enskilda incheckningarna. Sammanslagningsalgoritmen betraktar därför den ångrade ändringen som ingen ändring alls och ersätter den ändrade versionen istället.

KONFIGURATION

branch.<namn>.mergeOptions: Ställer in standardalternativ för sammanslagning till grenen <namn>. Syntaxen och de alternativ som stöds är desamma som för git merge, men alternativvärden som innehåller blanksteg stöds för närvarande inte.

Allt ovanför den här raden i det här avsnittet finns inte med i dokumentationen för git-config[1]. Innehållet som följer är detsamma som det som finns där:

merge.conflictStyle: Ange stilen med vilken konfliktfyllda stycken skrivs ut till arbetsträdfiler vid sammanslagning. Standardinställningen är "merge", som visar en <<<<<<< konfliktmarkör, ändringar gjorda av ena sidan, en =======-markör, ändringar gjorda av den andra sidan och sedan en >>>>>>> markör. En alternativ stil, "diff3", lägger till en |||||||| markör och originaltexten före =======-markören. Stilen "merge" tenderar att producera mindre konfliktområden än diff3, både på grund av att originaltexten utesluts och för att när en delmängd av rader matchar på de två sidorna, dras de bara 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 visas nära antingen början eller slutet av ett konfliktområde.
merge.defaultToUpstream: Om merge anropas utan något inchecknings-argument, sammanfogas de uppströmsgrenar som konfigurerats för den aktuella grenen med hjälp av deras senast observerade värden som lagrats i deras fjärrspårningsgrenar. Värdena för branch.<nuvarande gren>.merge som namnger grenarna på fjärrvärd namngiven av branch.<nuvarande gren>.remote konsulteras, och sedan mappas de via remote.<fjärrvärd>.fetch till deras motsvarande fjärrspårningsgrenar, och topparna för dessa spårningsgrenar sammanfogas. Standardvärdet är sant.
merge.ff: Som standard, skapar Git inte en extra sammanslagnings-incheckningar när den sammanfogar en incheckning som är en underordnad till den topen av aktuell incheckning. Istället snabbspolas spetsen för den aktuella grenen framåt. När den är satt till false, talar denna variabel om för Git att skapa en extra sammanslagnings-incheckning i ett sådant fall (motsvarande att ge alternativet --no-ff från kommandoraden). När den är satt till only, tillåts endast sådana snabbspolnings-sammanfogningar (motsvarande att ge alternativet --ff-only från kommandoraden).
merge.verifySignatures: Om sant, motsvarar detta kommandoradsalternativet --verify-signatures. Se git-merge[1] för mer information.
merge.branchdesc: Förutom grennamnen, fyll i loggmeddelandet med den grenbeskrivningstext som är associerad med dem. Standardvärdet är falskt.
merge.log: Förutom grennamn, fyll i loggmeddelandet med högst det angivna antalet enradsbeskrivningar från de faktiska incheckningar som sammanfogas. Standardvärdet är falskt, och sant är en synonym för 20.
merge.suppressDest: Genom att lägga till en glob som matchar namnen på integrationsgrenar till denna flervärdeskonfigurationsvariabel, kommer standardmeddelandet för sammanslagningar som beräknas för sammanslagningar i dessa integrationsgrenar att utelämna "into <gren-namn>" från titeln.

Ett element med ett tomt värde kan användas för att rensa listan över globs som ackumulerats från tidigare konfigurationsposter. När ingen variabel merge.suppressDest har definierats används standardvärdet master för bakåtkompatibilitet.

merge.renameLimit

Antalet filer som ska beaktas i den uttömmande delen av namnbytesdetektering under en sammanslagning. Om inget anges används standardvärdet diff.renameLimit. Om varken merge.renameLimit eller diff.renameLimit anges används standardvärdet för närvarande 7000. Denna inställning har ingen effekt om namnbytesdetektering är avstängd.

merge.renames

Huruvida Git detekterar namnbyten. Om det är satt till false är namnbytesdetektering inaktiverad. Om det är satt till true är grundläggande namnbytesdetektering aktiverad. Standardvärdet är diff.renames.

merge.directoryRenames

Huruvida Git detekterar katalogbyten, vilket påverkar vad som händer vid sammanslagningstillfället med nya filer som läggs till i en katalog på ena sidan av historiken när den katalogen döptes om på den andra sidan av historiken. Möjliga värden är:

false: Detektering av katalog-namnbyte är inaktiverat, vilket innebär att sådana nya filer kommer att lämnas kvar i den gamla katalogen.
true: Detektering av katalog namnbyte är aktiverat, vilket innebär att sådana nya filer flyttas till den nya katalogen.
conflict: En konflikt kommer att rapporteras för sådana sökvägar.

Om merge.renames är false ignoreras merge.directoryRenames och behandlas som false. Standardvärdet är conflict.

merge.renormalize

Informera Git om att den kanoniska representationen av filer i förvar har förändrats över tid (t.ex. tidigare incheckningar registrerade textfiler med CRLF radslut, men nyare använder LF radslut). I ett sådant förvar kan Git, för varje fil där en trevägs innehållssammanslagning behövs, konvertera data som registrerats i incheckningar till en kanonisk form innan en sammanslagning utförs för att minska onödiga konflikter. För mer information, se avsnittet "Sammanfoga grenar med olika inchecknings-/utcheckningsattribut" i gitattributes[5].

merge.stat

Vad, om något, ska skrivas ut mellan ORIG_HEAD och sammanslagningsresultatet 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.

men alla okända värden (t.ex. ett värde som läggs till av en framtida version av Git) tas som sant istället för att utlösa ett fel. Standardvärdet är sant.

merge.autoStash

När den är satt till true skapas automatiskt en tillfällig gömma-post innan operationen börjar och tillämpas efter att operationen är avslutad. Detta innebär att du kan köra merge på ett smutsigt arbetsträd. Använd dock med försiktighet: den slutliga stash-applikationen efter en lyckad merge kan resultera i icke-triviala konflikter. Detta alternativ kan åsidosättas av alternativen --no-autostash och --autostash i git-merge[1]. Standardvärdet är false.

merge.tool

Kontrollerar vilket sammanslagningsverktyg som används av git-mergetool[1]. Listan nedan visar de giltiga inbyggda värdena. Alla andra värden behandlas som ett anpassat sammanslagningsverktyg och kräver att en motsvarande mergetool.<verktyg>.cmd-variabel definieras.

merge.guitool

Styr vilket sammanslagningsverktyg som används av git-mergetool[1] när flaggan -g/--gui är specificerad. Listan nedan visar de giltiga inbyggda värdena. Alla andra värden behandlas som ett anpassat sammanslagningsverktyg och kräver att en motsvarande variabel mergetool.<gui-verktyg>.cmd definieras.

Warning

Missing sv/config/{build_dir}/mergetools-merge.adoc

See original version for this content.

merge.verbosity: Styr mängden utdata som visas av den rekursiva sammanslagningsstrategin. Nivå 0 matar ut ingenting förutom ett slutligt felmeddelande om konflikter upptäcktes. Nivå 1 matar endast ut konflikter, 2 matar ut konflikter och filändringar. Nivå 5 och högre matar ut felsökningsinformation. Standardinställningen är nivå 2. Kan åsidosättas av miljövariabeln GIT_MERGE_VERBOSITY.
merge.<förare>.name: Definierar ett människoläsbart namn för en anpassad lågnivå-sammanslagningsdrivrutin. Se gitattributes[5] för mer information.
merge.<förare>.driver: Definierar kommandot som implementerar en anpassad lågnivå-sammanslagningsdrivrutin. Se gitattributes[5] för mer information.
merge.<förare>.recursive: Namnger en lågnivå-sammanslagningsdrivrutin som ska användas vid intern sammanslagning mellan gemensamma förfäder. Se gitattributes[5] för mer information.

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]

En del av git[1]-sviten

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands