Opties en voorbeelden van de Git merge-strategie
Wanneer het werk voltooid, getest en klaar is om weer te worden samengevoegd in de hoofdlijn van het ontwikkelingsproces, moet je team een aantal beleidskeuzes maken. Wat zijn je opties voor een merge-strategie? In dit artikel bekijken we de mogelijkheden en maken we vervolgens enkele opmerkingen over hoe Atlassian werkt. Hopelijk heb je uiteindelijk de middelen om te beslissen wat het beste werkt voor jouw team.
Git Merge-strategieën
Een merge vindt plaats wanneer twee branches worden samengevoegd. Git heeft twee (of meer) commit-pointers nodig en zal proberen een gemeenschappelijke basis-commit tussen beide te vinden. Git heeft verschillende methoden om een basis-commit te vinden. Deze methoden worden 'merge-strategieën' genoemd. Zodra Git een gemeenschappelijke basis-commit heeft gevonden, wordt er een nieuwe 'merge commit' aangemaakt, die de wijzigingen van de merge commits combineert. Technisch gezien is een merge commit een gewone commit die twee bovenliggende commits heeft.
git merge selecteert automatisch een merge-strategie, tenzij expliciet anders aangegeven. Aan de opdrachten git merge en git pull kan de optie -s (strategie) worden doorgegeven. De optie -s kan worden toegevoegd met de naam van de gewenste merge-strategie. Indien niet expliciet gespecificeerd, selecteert Git de meest geschikte merge-strategie op basis van de aangeboden branches. Hieronder volgt een lijst met de beschikbare merge-strategieën.
gerelateerd materiaal
Uitgebreid Git log
Oplossing bekijken
Git leren met Bitbucket Cloud
Recursive
git merge -s recursive branch1 branch2Dit werkt op twee heads. Recursive is de standaard merge-strategie voor het pullen of samenvoegen van één branch. Bovendien kunnen hiermee merges met gewijzigde namen worden gedetecteerd en verwerkt, maar op dit moment kan er geen gebruik worden gemaakt van gedetecteerde kopieën. Dit is de standaard merge-strategie voor het pullen of samenvoegen van één branch.
Oplossen
git merge -s resolve branch1 branch2Hiermee kunnen alleen twee heads worden opgelost met een merge-algoritme voor drie richtingen. De strategie probeert dubbelzinnigheden van gekruiste merges zorgvuldig te detecteren en wordt over het algemeen beschouwd als veilig en snel.
Octopus
git merge -s octopus branch1 branch2 branch3 branchNDe standaard merge-strategie voor meer dan twee heads. Wanneer meer dan één branch wordt doorgegeven, wordt octopus automatisch ingeschakeld. Als een merge conflicten bevat die handmatig moeten worden opgelost, weigert octopus de samenvoeging uit te voeren. Deze strategie wordt voornamelijk gebruikt om heads van vergelijkbare functiebranches te koppelen.
Ours
git merge -s ours branch1 branch2 branchNDe Ours-strategie werkt op een veelvoud van N branches. Het uitgevoerde merge-resultaat is altijd dat van de huidige branch HEAD. De term 'ours' (onze) impliceert dat er een voorkeur is om alle wijzigingen uit alle andere branches effectief te negeren. De strategie is bedoeld om de geschiedenis van vergelijkbare functiebranches te combineren.
Subtree
git merge -s subtree branchA branchBDit is een uitbreiding van de Recursive-strategie. Als A en B worden samengevoegd en B een onderliggende subtree is van A, wordt B eerst bijgewerkt om de boomstructuur van A weer te geven. Deze update wordt ook uitgevoerd voor de gemeenschappelijke voorouderboom die A en B delen.
Soorten Git merge-strategieën
Explicit merge
Expliciete samenvoegingen zijn het standaard merge-type. Het 'expliciete' deel is dat ze een nieuwe merge commit aanmaken. Dit verandert de commitgeschiedenis en laat expliciet zien waar een merge is uitgevoerd. De inhoud van merge commit is ook expliciet omdat het laat zien welke commits de bovenliggende elementen waren van de merge commit. Sommige teams vermijden expliciete merges omdat de merge commits aantoonbaar 'ruis' toevoegen aan de geschiedenis van het project.
implicit merge via rebase of fast-forward merge
Squash bij samenvoegen, meestal zonder expliciete merge
Opties voor de Git-merge-strategie Recursive
De hierboven geïntroduceerde 'recursive' strategie heeft een eigen subset met aanvullende gebruiksopties.
oursVerwar dit niet met de merge-strategie Ours. Deze optie conflicteert en wordt automatisch netjes opgelost door de voorkeur te geven aan 'onze' versie. Wijzigingen van de 'hun' kant worden automatisch verwerkt als ze niet met elkaar in conflict zijn.
theirsHet tegenovergestelde van de 'onze' strategie. De 'hun' optie begunstigt de vreemde merging structuur bij het oplossen van conflicten.
patienceMet deze optie wordt extra tijd besteed aan het voorkomen van onjuiste merges op onbelangrijke overeenkomende regels. Deze optie wordt het best gebruikt wanneer de samen te voegen branches extreem uiteenlopend zijn.
diff-algorithimignore-*
ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eolEen set opties die gericht zijn op witruimtetekens. Elke regel die overeenkomt met de subset van de doorgegeven optie, wordt genegeerd.
renormalizeDeze optie checkt alle Git-structuren van de structuur uit en in en lost een merge in drie richtingen op. Deze optie is bedoeld voor branches die worden samengevoegd en die verschillende statussen hebben voor checkin en checkout.
no-normalizeSchakelt de optie hernormaliseren uit. Dit heeft voorrang op de configuratievariabele merge.renormalize.
no-renamesDeze optie negeert hernoemde bestanden tijdens de merge.
find-renames=nDit is het standaardgedrag. De recursieve merge zal bestandshernoemingen respecteren. De parameter n kan worden gebruikt om een drempelwaarde door te geven voor de gelijkende hernoeming. De standaardwaarde van n is 100%.
subtreeDeze optie is ontleend aan de `subtree'-strategie. Wanneer de strategie op twee structuren werkt en wijzigt hoe ze bij elkaar passen op een gedeelde voorouder, dan gebruikt deze optie in plaats daarvan de metagegevens van het pad van de structuur om ervoor te zorgen dat ze met elkaar in overeenstemming worden gebracht.
Ons merge-beleid voor Git
Atlassian geeft sterk de voorkeur aan expliciete merges. De reden is heel simpel: expliciete merges bieden een uitstekende traceerbaarheid en context voor de functies die worden samengevoegd. Een rebase om de lokale geschiedenis op te schonen alvorens een functiebranch ter beoordeling te delen is absoluut aan te raden, maar dit verandert het beleid helemaal niet. Het versterkt het.
Deel dit artikel
Volgend onderwerp
Aanbevolen artikelen
Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.
Bitbucket-blog
DevOps-leertraject
