För att slå samman en utvecklingsgren till den aktuella grenen, använd “git merge dev-branch-name “. Om du får konfliktvarningar om en sammanslagning, använd “git merge –abort” för att backa ur den, eller redigera de påverkade filerna och commit dem sedan.
Git använder grenar för att isolera utvecklingsströmmar, för att förhindra den stabila utgivningsgrenen från att bli förorenad. Att föra in arbete i en gren i huvudströmmen innebär att slå samman grenar. Så här gör du.
Innehållsförteckning
Vad är en sammanslagning i Git?
Förbereder att slå samman en gren i Git
Utför en sammanslagning
Utför en snabbspolning framåt i Git
Hur löser du sammanslagningskonflikter i Git
Allt smälter samman så småningom
Vad är en sammanslagning i Git?
Git designades för att göra förgrening enkel och snabb. Till skillnad från andra versionskontrollsystem är förgrening på Git en trivial sak. Särskilt i projekt med flera utvecklare är förgrening ett av Git’s kärnorganisationsverktyg.
Sandbox nya utvecklingsinsatser så att koden kan modifieras eller läggas till utan att påverka koden i andra grenar, särskilt huvud- eller huvudgren. Denna innehåller vanligtvis den stabila versionen av din kodbas.
Att isolera dessa ändringar från din stabila kodversion är helt logiskt. Men förr eller senare kommer den nya koden att testas, granskas och gummistämplas för att rullas in i mastergrenen. Vid det tillfället måste du slå samman din gren till huvudgrenen.
RELATERATHur fungerar Git-grenar?
Faktiskt kan grenar ha undergrenar så du kanske slår ihop din gren till någon annan gren istället för huvudgrenen. Kom bara ihåg att sammanslagningar alltid tar en gren och slår samman den till en målgren, oavsett vilken gren det är. Om du vill slå samman din huvudgren till en annan gren kan du till och med göra det också.
Som de flesta åtgärder i Git utför du sammanslagningar i ditt lokala arkiv och skjuter dem till ditt fjärrlager.
Förbereder för att slå samman en gren i Git
Vi har ett litet utvecklingsprojekt med ett lokalt Git-förråd och ett fjärrstyrt Git-förråd. Vi skapade en gren som heter “bugfix14” från “mästaren” filial och arbetade på en lösning på en bugg.
Det arbetet är slutfört och vi har testat vår kod. Det hela fungerar som förväntat. Vi vill rulla in dessa ändringar i huvudgrenen så att vår fix är en del av nästa version av programvaran.
Det återstår lite förberedelser innan vi utför sammanslagningen. Vi måste se till att målgrenen—i detta fall är “master” branch—och grenen vi ska slå samman i den är båda uppdaterade.
För att göra detta använder vi kommandot git status.
git status
- På branch bugfix14: Detta är vår nuvarande filial.
- Din filial är uppdaterad med ‘origin/bugfix’: Filialen i vårt lokala arkiv har samma commit-historik som filialen i fjärrförvar. Det betyder att de är identiska.
- inget att begå Det finns inga ändringar i uppställningsområdet som inte har begåtts.
- rengöring av arbetsträd: Det finns inga ostadgade ändringar i arbetskatalogen.
Alla dessa indikerar att grenen är uppdaterad, och vi är klara att fortsätta. Om någon av dessa indikerade att förändringar fanns, skulle vi behöva iscensätta dem, genomföra dem och skjuta dem till fjärrkontrollen. Om någon annan hade arbetat med dessa filer kan vi behöva hämta deras ändringar från fjärrförvaret.
Att kolla in grenen vi ska slås samman till förenklar sammanslagningsprocessen. Det låter oss också verifiera att den är uppdaterad. Låt oss ta en titt på huvudgrenen.
git checkout master git status
Vi får samma bekräftelser som “mästaren” filialen är uppdaterad.
RELATERAT: Hur man väljer Git Workflow & Branching Model som är rätt för ditt team
Utföra en sammanslagning
Innan vi sammanfogar ser våra åtaganden ut så här.
“bugfix14” filialen var förgrenad från “mästaren” gren. Det har gjorts ett åtagande till “mästaren” gren efter “buggfix14” filial skapades. Det har gjorts ett par åtaganden till “buggfix14” filial.
Vi har sett till att våra två filialer är uppdaterade och vi har kollat in “mästaren” gren. Vi kan utfärda kommandot för att slå samman “bugfix14” förgrena sig till “mästaren” branch.
git merge bugfix14
Sammanfogningen äger rum. “buggfix14” grenen finns fortfarande, men nu har ändringarna som gjordes i den grenen slagits samman till “master” filial.
I det här fallet utför kommandot merge en trevägs sammanslagning. Det finns bara två grenar, men det finns tre åtaganden inblandade. De är chefen för båda grenarna och en tredje commit som representerar själva sammanslagningsåtgärden.
För att uppdatera vårt fjärrlager kan vi använda kommandot git push.
git push
< img src="http://www.howtogeek.com/pagespeed_static/1.JiBnMqyl6S.gif" />
Vissa människor föredrar att ta bort sidogrenar när de väl har slagit ihop dem. Andra ser till att bevara dem som en registrering av projektets sanna utvecklingshistorik.
Om du vill ta bort grenen kan du göra det med kommandot git branch med alternativet -d (delete). .
git branch -d bugfix14
För att ta bort grenen i fjärrarkivet använder det här kommandot:
git push origin –delete bugfix14
Du kommer att ha en linjär commit-historik, men det kommer inte att vara den sanna historien.
RELATERAT: Hur man tar bort Git-grenar på lokala och fjärranslutna lagringsplatser
Utföra en Snabbspolning framåt i Git
Om du inte har gjort några åtaganden till “mästaren” gren kommer din historia att se ut så här. Det kommer också att se ut så här om du har baserat om din utvecklingsgren så att den är fäst i slutet av “master” filial.
Eftersom det inte finns några commits i “master” gren, för att slå samman “buggfix15” gren, allt Git behöver göra är att peka på “mästaren” huvudpekare till den sista bekräftelsen av “buggfix15” branch.
Vi kan använda det vanliga git merge-kommandot:
git merge bugfix15
Det ger oss det här resultatet.
Som är samma som detta:
Som är precis samma sak som denna:
Git kommer att utföra en snabbspolning framåt närhelst den kan. If förbinder sig till “mästaren” gren betyder att snabbspolning framåt inte är möjlig, Git kommer att använda en trevägs sammanslagning.
Du kan inte tvinga en snabbspolning framåt—det kanske inte är möjligt trots allt—men du kan förklara att det kommer att bli snabbspolning framåt eller inget. Det finns ett alternativ som instruerar Git att använda en snabbspolning framåt om den kan, men inte att göra en trevägs sammanslagning om den inte kan. Alternativet är –ff-only (endast snabbspolning framåt).
Detta slår samman “bugfix15” förgrena sig till “mästaren” gren, men bara om en snabbspolning framåt är möjlig.
git merge –ff-only bugfix15
Git kommer att klaga och avsluta om det inte är möjligt.
git merge –ff-only bugfix16
I det här fallet har det skett åtaganden till “master” gren, så en snabbspolning framåt är inte möjlig.
Hur man löser sammanslagningskonflikter i Git
Om samma delar av samma fil har ändrats i båda grenarna kan grenarna inte slås samman. Mänsklig interaktion krävs för att lösa de motstridiga ändringarna.
Här har vi gjort ändringar i en fil som heter “rot.c” i en gren som heter “bugfix17” att vi vill slås samman till “mästaren” gren. Men “rot.c” har ändrats i “master” filial också.
git merge bugfix17
När vi försöker slå samman det får vi en varning om att det finns konflikter. Git listar de motstridiga filerna och berättar att sammanslagningen misslyckades. Vi skulle kunna backa helt med –abort-alternativet:
git merge –abort
Men att lösa sammanslagningar är inte så skrämmande som det låter. Git har gjort en del arbete för att hjälpa oss. Om vi redigerar en av de motstridiga filerna—i vårt fall, har vi bara en—vi’finner de motstridiga kodavsnitten markerade för oss.
Varje konflikt begränsas av sju mindre än tecken “<<<<<<<” och sju större än tecken “>>>>>>>“, med sju likhetstecken “=======” mellan dem.
- Koden ovanför likhetstecknet är från grenen du slår samman i.
- Koden under likhetstecknet är koden från grenen. du försöker slå samman.
Du kan enkelt söka efter en av uppsättningarna med sju tecken och gå från konflikt till konflikt genom din fil. För varje konflikt måste du välja vilken uppsättning redigeringar du ska behålla. Du måste redigera bort koden du avvisar och raderna med sju tecken som Git har lagt till.
Vi kommer att behålla koden från “buggfix17” ; gren. Efter redigering ser vår fil ut så här.
Vi kan fortsätt nu med sammanslagningen. Men observera att vi använder kommandot commit för att göra det, inte sammanfogningskommandot.
Vi genomför ändringen genom att iscensätta filen och begå den som vanligt. Vi kontrollerar statusen innan vi gör den sista commit.
git add rot.c git status git commit -m “Merged bugfix17”
Sammanfogningen är klar. Vi kan nu skicka detta till vårt fjärrlager.
RELATERAT: Hur man åtgärdar, redigerar eller ångrar Git Commits (Ändra Git-historik)
Allt slår samman så småningom
Alla grenar måste slås samman så småningom så att förändringarna i dem inte blir föräldralösa och glömda.
Att slå samman grenar är enkelt, men att hantera med konflikter kan bli komplicerade i upptagna, större team. Att lösa konflikter kan kräva input från varje utvecklare bara för att förklara vad deras kod gör och varför de gjorde sina ändringar. Du måste förstå det innan du kan fatta ett välgrundat beslut om vilka redigeringar du ska behålla.
Tyvärr kan Git inte hjälpa till med det.
RELATERAT: Bör du använda en GUI Git-klient?
LÄS NÄSTA
- › Varför vill webbplatser alltid att jag ska använda deras appar?
- › Ska du lita på ditt VPN?
- › Skaffa en reserouter för att uppgradera din Wi-Fi-upplevelse på hotell
- › Så här installerar du Amazon Appstore på en Android-telefon
- › Så här delar du din skärm på Discord
- › Hur skärmsläckare bokstavligen sparar din skärm