Git bruger grene til at isolere udviklingsstrømme for at forhindre, at den stabile frigivelsesgren bliver forurenet. At bringe arbejde i en gren ind i hovedstrømmen betyder sammenlægning af grene. Sådan gør du det.
Hvad er en fusion i Git?
Forbereder sig på at flette en gren i git
Udfører en fusion
Udfører en hurtig fremadrettet fusion i Git
Hvordan man løser fletningskonflikter i git
Alt smelter sammen til sidst
Hvad er en fusion i Git?
Git var designet til at gøre forgrening enkel og hurtig. I modsætning til andre versionskontrolsystemer er forgrening på Git en triviel sag. Især på multieveloper-projekter er forgrening et af GITs centrale organisatoriske værktøjer.
Grener Sandkasse Ny udviklingsindsats, så koden kan ændres eller tilføjes uden at påvirke koden i andre grene, især hoved- eller mastergrenen. Dette indeholder normalt den stabile version af din kodebase.
Isolering af disse ændringer fra din stabile kodeversion giver perfekt mening. Men før eller senere vil den nye kode blive testet, gennemgået og gummi-stemplet for at blive rullet ind i masterfilialen. På det tidspunkt skal du flette din gren ind i mastergrenen.
Faktisk kan grene have undergrene, så du kan muligvis fusionere din gren i en anden gren i stedet for mastergrenen. Husk bare, at fusion altid tager en gren og flet den ind i en mål gren, uanset hvilken gren der måtte være. Hvis du vil fusionere din mastergren i en anden gren, kan du endda gøre det.
Som de fleste handlinger i Git udfører du fusioner i dit lokale depot og skubber dem til dit fjernlager.
Forbereder sig på at flette en gren i git
Vi har et lille udviklingsprojekt med et lokalt git -arkiv og et fjerntliggende Git -lager. Vi oprettede en filial kaldet “Bugfix14” fra “Master” -grenen og arbejdede på en løsning på en fejl.
Dette arbejde er afsluttet, og vi har testet vores kode. Det hele fungerer som forventet. Vi ønsker at rulle disse ændringer til masterfilialen, så vores rettelse er en del af den næste udgivelse af softwaren.
Der er en lille forberedelse, der skal gøres, før vi udfører fusionen. Vi er nødt til at sørge for, at målgrenen - i dette tilfælde "master" -grenen - og den gren, vi skal smelte sammen med den, begge er ajour.
- På filial Bugfix14 : Dette er vores nuværende gren.
- Din gren er opdateret med 'Oprindelses/bugfix' : Filialen i vores lokale depot har den samme forpligtelseshistorie som filialen i fjernlageren. Det betyder, at de er identiske.
- intet at begå Der er ingen ændringer i iscenesættelsesområdet, der ikke er begået.
- Arbejdstræ rent : Der er ingen ustillede ændringer i arbejdsmappen.
Alle disse indikerer, at grenen er ajour, og vi er klare at fortsætte. Hvis nogen af disse indikerede, at der eksisterede ændringer, var vi nødt til at arrangere dem, forpligte dem og skubbe dem til fjernbetjeningen. Hvis en anden havde arbejdet med disse filer, er vi muligvis nødt til at trække deres ændringer fra fjernlageren.
At tjekke den gren, vi vil smelte sammen med at forenkle fusionsprocessen. Det giver os også mulighed for at verificere, at det er ajour. Lad os se på masterfilialen.
Vi får de samme bekræftelser om, at "master" -filialen er ajour.
RELATEREDE: Sådan vælger du Git Workflow & amp; Filialmodel, der er rigtigt for dit team
Udfører en fusion
Grenen "Bugfix14" blev forgrenet fra "master" -grenen. Der har været en forpligtelse til "master" -grenen, efter at "Bugfix14" -filialen blev oprettet. Der har været et par forpligtelser til grenen “Bugfix14”.
Vi har sørget for, at vores to grene er ajour, og vi har tjekket "Master" -filialen. Vi kan udstede kommandoen til at flette "Bugfix14" -grenen i "master" -grenen.
Merge finder sted. Grenen "Bugfix14" eksisterer stadig, men nu er de ændringer, der blev foretaget i denne gren, blevet fusioneret til "master" -grenen.
I dette tilfælde udfører Merge -kommandoen en Tre-vejs fusion . Der er kun to filialer, men der er tre forpligtelser involveret. De er lederen af begge grene og en tredje forpligtelse, der repræsenterer selve flethandlingen.
For at opdatere vores fjernlager kan vi bruge Git push kommando.
Nogle mennesker foretrækker at slette sidegrener, når de har fusioneret dem. Andre sørger for at bevare dem som en registrering af projektets sande udviklingshistorie.
Hvis du vil slette grenen, kan du gøre det ved hjælp af
git gren
Kommando med
-d
(Slet) mulighed.
Til Slet grenen Brug denne kommando i fjernlager denne kommando:
Du har en lineær commithistorie, men det vil ikke være den sande historie.
RELATEREDE: Sådan slettes Git -filialer på lokale og fjerntliggende lagre
Udfører en hurtig fremadrettet fusion i Git
Hvis du ikke har gjort nogen forpligtelse til "master" -grenen, vil din historie se sådan ud. Det vil også se dette ud, hvis du har Genoprettet Din udviklingsgren, så den er knyttet til slutningen af "master" -grenen.
Fordi der ikke er nogen forpligtelser i "master" -grenen til at flette "Bugfix15" -grenen, er alt Git at gøre er at pege "Master" -hovedpointeren til den sidste engagement i "Bugfix15" -grenen.
Git udfører en hurtig fremadrettet fusion når det kan . Hvis forpligtelse til "master" -grenen betyder, at en hurtig fremadrettet fusion ikke er mulig, vil Git bruge en Tre-vejs fusion .
Du kan ikke
kraft
En hurtig fremadrettet fusion-det måske ikke muligt, trods alt-men du kan erklære, at det vil blive hurtigt fremadrettet fusion eller intet. Der er en mulighed, der instruerer Git til at bruge en hurtig fremadrettet fletning, hvis den kan, men ikke at gøre en trevejs fusion, hvis den ikke kan. Indstillingen er
-kun
(kun fremadrettet fletning).
Dette fusionerer "Bugfix15" -grenen i "master" -grenen, men kun hvis en hurtig fremadrettet fletning er mulig.
I dette tilfælde har der været forpligtet til "master" -grenen, så en hurtig fremadrettet fletning er ikke mulig.
Hvordan man løser fletningskonflikter i git
Hvis de samme dele af den samme fil er ændret i begge grene, kan grenene ikke fusioneres. Menneskelig interaktion er påkrævet for at løse de modstridende redigeringer.
Her har vi foretaget ændringer i en fil kaldet “rot.c” i en gren kaldet “Bugfix17”, som vi vil fusionere til "master" -grenen. Men "Rot.C" er også blevet ændret i "master" -grenen.
Når vi prøver at fusionere det, får vi en advarsel om, at der er konflikter. Git viser de modstridende filer og fortæller os, at fusionen mislykkedes. Vi kunne slå os helt tilbage ved hjælp af
--abort
mulighed:
Men at løse fusion er ikke så skræmmende, som det lyder. Git har gjort noget arbejde for at hjælpe os. Hvis vi redigerer en af de modstridende filer - i vores tilfælde, har vi kun en - vi finder de modstridende kodesektioner, der er fremhævet for os.
Hver konflikt er afgrænset af syv mindre end karakterer "
& lt; & lt; & lt; & lt; & lt; & lt; & lt;
”Og syv større end karakterer“
& gt; & gt; & gt; & gt; & gt; & gt; & gt;
“, Med syv lige tegn”
=======
" mellem dem.
- Koden over de ligestillede tegn er fra den gren, du fusionerer ind i .
- Koden nedenfor er ligestegn koden fra den gren, du prøver på fusionere .
Du kan nemt søge efter et af sættet af syv karakterer og flytte fra konflikt til konflikt gennem din fil. For hver konflikt skal du vælge hvilket sæt redigeringer, du vil beholde. Du skal redigere den kode, du afviser, og de syv-tegnlinjer, som Git har tilføjet.
Vi vil holde koden fra "Bugfix17" -grenen. Efter redigering ser vores fil sådan ud.
Vi kan nu fortsætte med fusionen. Men bemærk, vi bruger
begå
kommando til at gøre det, ikke
fusionere
kommando.
Vi begår ændringen ved at iscenesætte filen og forpligte den som sædvanligt. Vi tjekker status, før vi foretager den endelige forpligtelse.
Fusionen er komplet. Vi kan nu skubbe dette til vores fjernlager.
RELATEREDE: Hvordan man løser, rediger eller fortryder git -forpligtelser (ændrer git historie)
Alt smelter sammen til sidst
Alle grene skal til sidst blive fusioneret, så ændringerne i dem ikke bliver forældreløse og glemt.
Det er let at fusionere grene, men at håndtere konflikter kan blive kompliceret i travle, større hold. Løsning af konflikter kan kræve input fra hver udvikler bare for at forklare, hvad deres kode gør, og hvorfor de foretog deres ændringer. Du skal forstå det, før du kan tage en informeret beslutning om, hvilke redigeringer der skal opbevares.
- › Sådan omdøber du en gren i Git
- › Hvordan man tjekker en ekstern git gren
- › Hvordan man stash ændringer i git
- › Hvordan man skifter grene i github
- › Git Rebase: Alt hvad du har brug for at vide
- › OnePlus 11 er her, men med en hård start
- › Microsoft Edge får AI -chat og et nyt look på Windows
- › De bedste ørepropper til iPhone -fans ramte bare deres laveste pris
