Met alles wat je er te doen valt binnen een ontwikkelingsproject, kan je stellen dat Git een ware uitkomst is. Maar als je veel mensen op de dansvloer hebt, zullen er ongetwijfeld een of twee op elkaars tenen gaan staan. Voor jouw project betekent dit dat twee developers aan dezelfde code kunnen werken en beiden commits moeten maken. Voor deze situaties bieden Git merge strategieën uitkomst om dit conflict op te lossen.
Hoewel een Git merge eenvoudig kan zijn, zijn er vaak andere momenten waarop een geavanceerde aanpak vereist is. Je zult dus strategieën moeten gebruiken zoals recursief mergen, drie-wegs merges en nog veel meer. Het kan zelfs zo zijn dat je op een gegeven moment een Git merge ongedaan moet maken.
Deze tutorial bespreekt een aantal complexe Git merge technieken om aan je arsenaal toe te voegen. Laten we meteen beginnen!
Inleiding: Git merge strategieën
Het kernconcept van een merge is eenvoudig: je voegt twee branches samen om meerdere commits in één te veranderen. Er zijn echter een aantal technieken die je kunt gebruiken om er zeker van te zijn dat je de juiste code commit en samenvoegt.
We gaan hier kijken naar een paar belangrijke strategieën die je onder de knie wilt hebben. Ze staan niet op volgorde en op een bepaald moment in je ontwikkelcarrière kun je ze allemaal nodig hebben. Bovendien zul je ook een goed begrip willen hebben van de basisconcepten van Git, zoals pointers, branches en commits.
Het verschil tussen twee- en driewegs merges
Het is handig om het verschil te begrijpen tussen een tweewegs merge en zijn driewegs equivalent. De meeste merge strategieën die we hierna behandelen gaan over driewegs situaties. Het is goed om het even te hebben over wat een driewegs merge is. Neem het volgende voorbeeld:
- Je hebt een main branch met een aantal commits en een feature branch die ook commits heeft.
- Echter, als de main branch nu verdere commits uitvoert, zullen beide branches divergeren.
- Simpel gezegd: zowel main als de feature branch hebben commits die de ander niet heeft. Als je deze merget met een tweerichtings aanpak, verlies je een commit (waarschijnlijk op main.)
- In plaats daarvan zal Git een nieuwe merge commit maken van zowel de huidige main als de feature branch.
Heel kort door de bocht zal Git naar drie verschillende snapshots kijken om wijzigingen te mergen: het hoofd van main, het hoofd van de feature branch, en de gemeenschappelijke parent. Dit zal de laatste commit zijn die gemeenschappelijk is voor zowel main als de feature branch.
In de praktijk hoef je je geen zorgen te maken of een bepaalde merge strategie twee- of drieweg is. Vaak moet je een strategie hoe dan ook gebruiken. In ieder geval is het handig om te weten hoe Git ‘denkt’ als het aankomt op het mergens van branches en repo’s.
Fast-forward mergen
Bij de eerste strategie hoef je misschien geen actie uit te voeren om het uit te voeren. Een fast-forward merge verplaatst de pointer naar de laatste commit op main zonder een extra commit aan te maken (wat verwarrend kan zijn.) Het is een nette aanpak die veel developers standaard zullen gebruiken.
De techniek begint met een main branch die al dan niet commits kan hebben. In dit geval open je een nieuwe branch, werk je aan de code en maak je commits. Op dit punt moet je die wijzigingen ook terug naar de main mergen. Een fast-forward merge heeft één vereiste om uit te voeren:
- Je moet ervoor zorgen dat er geen andere commits plaatsvinden op main terwijl je aan je nieuwe branch werkt.
Dit zal niet altijd mogelijk zijn, vooral als je in een groot team werkt. Als je er desondanks voor kiest om je commits te mergen met een main branch die actueel is en zonder eigen commits, dan zal dit een fast-forward merge uitvoeren. Je kunt dit op een paar verschillende manieren doen:
git merge <branch>
git merge --ff-only
Vaak hoef je niet aan te geven dat je een fast-forward merge wilt uitvoeren. Dit type merges komt voor bij soloprojecten of projecten met kleine teams. In een omgeving waarin veel tegelijk gebeurt, is dit een zeldzame merge en zul je vaak andere zien.
Recursief mergen
Een recursieve merge is vaak de standaard, simpelweg omdat deze vaker voorkomt dan andere soorten merges. Een recursieve merge is wanneer je commits uitvoert op een branch, maar verdere commits gebeuren ook op main.
Als het tijd is om samen te voegen, zal Git recursief over de branch gaan om de definitieve commit te doen. Dit betekent dat een merge commit twee parents zal hebben als je hem voltooid hebt.
Net als met een fast-forward merge, zul je normaal gesproken geen recursieve merge hoeven te specificeren. Je kunt ervoor zorgen dat Git niet voor bijvoorbeeld een fast-forward merge kiest door de volgende commando’s en flags te gebruiken:
git merge --no-ff
git merge -s recursive <branch1> <branch2>
De tweede regel gebruikt de -s strategie optie en expliciete naamgeving om een merge uit te voeren. In tegenstelling tot een fast-forward merge, creëert een recursieve merge een speciale merge commit. Voor merges in twee richtingen is een recursieve strategie solide en werkt goed.
Ours en theirs
Een veel voorkomende situatie tijdens ontwikkeling is die waarbij je een nieuwe feature binnen je project creëert die uiteindelijk geen groen licht krijgt. In veel gevallen moet je veel code mergen die ook afhankelijk is van elkaar. Een ‘ours’ merge is de beste manier om deze conflicten op te lossen.
Dit type merge kan zoveel branches aan als je nodig hebt en negeert alle wijzigingen op die andere branches. Het is geweldig als je een opruiming wil doen van oude features of ongewenste ontwikkeling. Hier is het commando dat je nodig hebt:
git merge -s ours <branch1> <branch2>Een ours merge betekent in wezen dat de huidige branch de jure de code bevat. Dit sluit aan bij ’theirs’ merges, die de andere branch als correct behandelt. Je moet hier echter een andere strategie optie doorgeven:
git merge -X theirs <branch2>
Het gebruik van ours en theirs merges kan verwarrend zijn, maar het is over het algemeen veilig om je aan de typische use cases te houden (die van het behouden van alles in de huidige branch en het weggooien van de rest).
Octopus
Dealen met meerdere heads – d.w.z. meer dan één branch mergen in een andere – kan een lastig scenario zijn voor een git merge. Met andere woorden, je hebt meer dan twee handen nodig hebt om de conflicten op te lossen. Dit is perfect voor een octopus merge.
Octopus merges zijn als het ware het tegenovergestelde van ours en theirs merges. De typische use case is dat je meerdere commits voor vergelijkbare feature wilt mergen tot één. Dit is hoe je het doorgeeft:
git merge -s octopus <branch1> <branch2>
Git zal echter een octopus merge weigeren als je een handmatige resolutie moet maken. Voor automatische resoluties zal een octopus merge standaard zijn als je meerdere branches tot één moet samenvoegen.
Resolve
Eén van de veiligste manieren om commits samen te voegen is een resolve merge, perfect voor als je een situatie hebt met criss-cross merges. Het is daarnaast een snelle resolutiemethode die je kan implementeren. Je wilt deze wellicht ook gebruiken voor complexere merge histories – maar alleen met twee heads.
git merge -s resolve <branch1> <branch2>
Omdat een resolve merge een drieweg algoritme gebruikt om te werken met zowel je huidige branch als de branch waar je vanaf pullt, is het misschien niet zo flexibel als andere merge methoden. Echter, voor de specifieke use case waarvoor je hem nodig hebt, is een resolve merge bijna perfect.
Subtree
Deze partner van een recursieve merge kan je mogelijk verwarren. We zullen proberen dit uit te leggen aan de hand van een duidelijk voorbeeld:
- Neem eerst twee verschillende trees- X en Y. Dit zullen vaak twee repo’s zijn.
- Je wilt beide trees samenvoegen tot één.
- Als tree Y overeenkomt met een van de subtrees in X, dan wordt tree Y gewijzigd om overeen te komen met de structuur van X.
Dit betekent dat een subtree merge fantastisch is als je meerdere repo’s wilt combineren tot één definitieve. Het zal ook de nodige wijzigingen aanbrengen in de gemeenschappelijke ‘ancestor’-tree van beide branches.
git merge -s subtree <branch1> <branch2>
Een subtree merge is dus wat je zoekt als je twee repositories wilt combineren. Het is goed mogelijk dat je moeite hebt om te begrijpen welke merge strategie voor jou de juiste is. Verder in dit artikel bespreken we een paar tools die je hierbij kunnen helpen.
Maar voordat we dit doen, zijn er een aantal geavanceerde merge conflicten waarvan je moet weten hoe je ze oplost.
Zo ga je om met meer complexe Git merge conflicten
Het mergen van branches in Git komt in de praktijk vaak neer op het managen en het oplossen van conflicten. Hoe groter je team en project, hoe groter de kans op conflicten. Sommige daarvan kunnen complex zijn en moeilijk op te lossen.
Gezien hoe conflicten tijd, geld en middelen kunnen opslokken, is het belangrijk om te weten hoe je ze snel in de kiem kunt smoren. In de meeste gevallen werken twee developers aan hetzelfde pakket code en besluiten ze allebei om een commit te doen.
Soms kan dit betekenen dat je de merge helemaal niet kunt starten vanwege wijzigingen die op pending staan of dat er een fout optreedt tijdens de merge die handmatig ingrijpen vereist. Zodra je werkdirectory ‘schoon’ is kun je beginnen. Vaak zal Git je op de hoogte stellen van een conflict bij het starten van een merge:
Voor meer informatie kun je een git status uitvoeren en de details bekijken:
Nu kun je beginnen te werken aan de verschillende bestanden die het conflict veroorzaken. De tools en technieken die we hieronder bespreken zullen je helpen.
Merges afbreken en resetten
Soms moet je de merge helemaal stoppen en met een schone lei beginnen. In feite zijn beide commando’s die we noemen geschikt voor situaties waarin je nog niet weet wat je met een conflict moet doen.
Je kunt ervoor kiezen om een merge die bezig is af te breken of te resetten met de volgende commando’s:
git merge --abort
git reset
De twee commando’s lijken op elkaar, maar je gebruikt ze in verschillende omstandigheden. Het afbreken van een merge zal de branch terugzetten naar de status van voor de merge. In sommige gevallen zal dit echter niet werken. Als je working directory bijvoorbeeld niet-gecommitte en niet-gestashte wijzigingen bevat, zul je geen abort kunnen uitvoeren.
Een merge reset betekent dat je de bestanden terugdraait naar een bekende ‘goede’ state. Dit laatste is iets om te overwegen als Git er niet in slaagt om de merge te starten. Merk op dat dit commando alle wijzigingen zal verwijderen die je niet commit, wat betekent dat dit een handeling is die zorgvuldigheid vereist.
Conflicten checken
De meeste merge conflicten zullen eenvoudig te achterhalen en op te lossen zijn. In sommige gevallen zul je echter dieper moeten graven om erachter te komen waarom een conflict ontstaat en hoe je het kunt oplossen.
Je kunt meer context krijgen na een git merge door een checkout te gebruiken:
git checkout --conflict=diff3 <filename>
Met dit commando pak je de typische navigatie die een checkout je geeft en maak je een vergelijking tussen de twee bestanden die het conflict laat zien:
In technische zin wordt het bestand opnieuw gecontroleerd en worden de conflictmarkers vervangen. Je kunt dit een paar keer doen tijdens een resolutie. Als je hier het argument diff3 doorgeeft, krijg je de basisversie en alternatieven in de ‘ours’ en ’theirs’ versies.
Let op dat de standaard argumentoptie merge is, die je niet hoeft te specificeren tenzij je de stijl van het merge confict wijzigt ten opzichte van de standaard.
Negatieve ruimte negeren
Negatieve ruimte en het gebruik ervan is een veel voorkomend discussiepunt. Elke programmeertaal gebruikt zijn eigen spacing en zelfs individuele developers gebruiken verschillende opmaak.
Of je spaties of tabs moet gebruiken is een discussiepunt waar we onze handen niet aan vuil zullen maken. Als je echter situaties hebt waarbij je de opmaak van de een naar de ander verandert, afhankelijk van het bestand en de codeerstandaard, dan zou je tegen dit Git merge probleem aan kunnen lopen.
Je zult weten dat dit de reden is waarom de merge mislukt, omdat er regels verwijderd en toegevoegd zullen zijn als je naar het conflict kijkt:
Dit komt omdat Git naar die regels kijkt en de negatieve ruimte als een wijziging beschouwt.
Je kunt echter specifieke argumenten toevoegen aan het git merge commando dat negatieve spaties in de relevante bestanden over het hoofd zal zien:
git merge -Xignore-all-space
git merge -Xignore-space-change
Hoewel deze twee argumenten op elkaar lijken, hebben ze een uniek verschil. Als je ervoor kiest om alle negatieve ruimte te negeren, dan zal Git dat doen. Het is een brede benadering, maar in tegenstelling tot -Xignore-space-change zal het alleen reeksen van één of meer negatieve spaties als gelijkwaardig tellen. Als zodanig zal het enkele spaties aan het eind van regels negeren.
Voor extra veiligheid kun je de merge ook controleren met het --no-commit commando, om te controleren of je negatieve spaties op de juiste manier negeert en telt.
Logs mergen
Loggen is cruciaal voor bijna elk stuk software dat data doorgeeft. Bij Git kun je de logs gebruiken om meer details over een merge conflict te achterhalen. Je hebt toegang tot deze informatie met git log:
Het is in wezen een tekstbestand dat elke actie binnen een repo dumpt. Je kunt echter verdere argumenten toevoegen om de weergave te verfijnen en alleen de commits te zien die je wilt:
git log --oneline --left-right <branch1>...<branch2>
Dit gebruikt een ‘Triple Dot’ om een lijst te geven van commits die betrokken zijn bij twee branches tijdens een merge. Het zal alle commits filteren die beide branches delen, wat een selectie van commits overlaat die je verder kan onderzoeken.
Je kunt ook git log --oneline --left-right --merge gebruiken om alleen commits te laten zien aan beide kanten van een merge die een conflicterend bestand ‘aanraken’. De -p optie zal je de exacte wijzigingen voor een specifieke ‘diff’ laten zien, maar merk op dat dit alleen geldt voor commits die niet samengevoegd zijn. Hier is een omweg voor, die we hierna behandelen.
Het combined diff format gebruiken om een Git merge conflict te onderzoeken
Je kunt de view die je krijgt met git log verder gebruiken om merge conflicten te onderzoeken. In normale omstandigheden zal Git code samenvoegen en alles dat lukt gaan stagen. Dit laat alleen de conflicterende regels over, en die kun je zien met het git diff commando:
Dit ‘combined diff’ format voegt twee extra kolommen met informatie toe. De eerste vertelt je of een regel verschilt tussen jouw (‘ours’) branch en de working copy; de tweede geeft je dezelfde informatie voor de ’theirs’ branch.
Wat tekens betreft geeft een plusteken aan of een regel een toevoeging is aan de working copy, maar niet in die specifieke kant van de merge, en een minteken geeft aan of de regel verwijderd is.
Merk op dat je dit combined diff format ook in Git’s log kunt zien door een paar commando’s te gebruiken:
git show
git log --cc -p
Het eerste is een commando dat je gebruikt op een merge commit om zijn geschiedenis te zien. Het tweede commando gebruikt de functionaliteit van -p om veranderingen aan een niet-merge commit naast het combined diff format te laten zien.
Zo maak je een Git merge ongedaan
Fouten kunnen gebeuren, en je kunt merges uitvoeren waar je later spijt van krijgt. In sommige gevallen kun je eenvoudig de meest recente commit wijzigen met git commit --amend. Dit zal de editor openen zodat je het laatste commit bericht kunt wijzigen.
Hoewel je complexere merge conflicten en de resulterende wijzigingen kunt terugdraaien, kan het lastig zijn omdat commits vaak permanent zijn.
Als zodanig zijn er veel stappen die je moet volgen:
- Ten eerste moet je commits bekijken en verwijzingen vinden naar de merges die je nodig hebt.
- Vervolgens moet je branches checkouten om commit histories te bekijken.
- Als je eenmaal kennis hebt opgedaan van de branches en commits die je nodig hebt, zijn er specifieke Git commando’s die je moet uitvoeren op basis van de door jou gewenste actie.
Laten we alles in meer detail bekijken en beginnen met het reviewproces. Van daaruit kunnen we je een snelle manier laten zien om een Git merge ongedaan te maken, en dan kijken naar specifieke commando’s voor meer geavanceerde use cases.
Commits reviewen
Het git log --oneline commando is geweldig als je de revisie ID’s en commit berichten met betrekking tot de huidige branch wilt zien:
Het git log --branches=* commando zal je dezelfde informatie laten zien, maar dan voor alle branches. Je kunt de referentie ID’s naast een git checkout gebruiken om een ‘detached HEAD‘ state te maken. Dit betekent dat je technisch gezien op geen enkele branch werkt, en zodra je terugschakelt naar een gevestigde branch, ‘orphan’ je de wijzigingen.
Als zodanig kun je de checkout bijna als een risicovrije speeltuin gebruiken. Echter, als je de wijzigingen wilt behouden, kun je de branch checkouten en een nieuwe naam geven met git checkout -b <branch-name>. Dit is een goede manier om een Git merge ongedaan te maken, maar er zijn meer genuanceerde manieren om dit te doen voor geavanceerd gebruik.
Git reset gebruiken
Veel van je merge conflicten zouden op een lokale repo kunnen plaatsvinden. In deze gevallen is git reset het commando dat je nodig hebt. Dit commando heeft echter meer parameters en argumenten die je wil kennen. Hier lees je hoe je het commando in de praktijk gebruikt:
git reset --hard <reference>
Het eerste deel hiervan – git reset --hard – doorloopt drie stappen:
- Het verplaatst de reference branch naar zijn locatie voor de merge commit.
- De harde reset zorgt ervoor dat de ‘index’ (d.w.z. de volgende voorgestelde commit snapshot) eruit ziet als de reference branch.
- Het laat de working directoy eruit zien als de index.
Zodra je dit commando gebruikt, verwijdert de commit historie latere commits en reset het de historie naar de gerefereerde ID. Het is een nette manier om een Git merge ongedaan te maken, maar het is niet geschikt voor alle use cases.
Je zult bijvoorbeeld een fout veroorzaken als je een lokale reset commit naar een remote repo probeert te pushen die die commit bevat. In dit scenario is er een ander commando dat je kunt gebruiken.
Git revert gebruiken
Hoewel git reset en git revert op elkaar lijken, zijn er een paar belangrijke verschillen. In de voorbeelden tot nu toe, houdt het ongedaan maken in het verplaatsen van de referentie-aanwijzers en HEAD naar een specifieke commit. Het lijkt op het schudden van speelkaarten om een nieuwe volgorde te maken.
In tegenstelling hiermee creëert git revert een nieuwe commit gebaseerd op backtracking wijzigingen, werkt dan de referentiepunten bij en maakt de branch de nieuwe ’tip’ Dit is ook waarom je dit commando zou moeten gebruiken voor remote repo samenvoeg conflicten.
Je zou git revert <reference> kunnen gebruiken om een Git merge ongedaan te maken. Merk op dat je altijd een commit referentie moet specificeren, anders zal het commando niet uitvoeren. Je kunt ook HEAD aan het commando meegeven om terug te keren naar de laatste commit.
Je kunt Git echter meer duidelijkheid geven over wat je wilt doen:
git revert -m 1 <reference>
Als je de merge aanroept, zal de nieuwe commit twee ‘ouders’ hebben De ene heeft betrekking op de referentie die je opgeeft, en de andere is de top van de branch die je wilt samenvoegen. In dit geval vertelt -m 1 Git om de eerste ouder – d.w.z. de gespecificeerde referentie – als de ‘hoofdlijn’ te houden.
De standaard optie voor git revert is -e of --edit. Dit zal de editor openen om de commit boodschap aan te passen voordat je terugdraait. Je kunt echter ook --no-edit opgeven, wat de editor niet zal openen.
Je kunt ook -n of --no-commit doorgeven. Dit vertelt git revert om geen nieuwe commit aan te maken, maar de wijzigingen ‘om te keren’ en ze toe te voegen aan de staging index en de werkmap.
Het verschil tussen merging vs rebasing in Git
In plaats van het git merge commando te gebruiken, kun je ook git rebase gebruiken. Dit is ook een manier om wijzigingen in één map te integreren, maar met een verschil:
- Een driewegs merge is de standaard als je
git mergegebruikt. Het combineert snapshots van twee huidige branches en voegt het samen met een gemeenschappelijke ancestor van beide om een nieuwe commit te maken. - Rebasen houdt in dat je een gepatchte wijziging van een afwijkende branch neemt en toepast op een andere, zonder de ancestor nodig te hebben. Dit betekent dat er geen nieuwe commit zal zijn.
Om dit commando te gebruiken, checkout je naar een branch waar je naar wilt rebasen. Vanaf daar kun je het volgende commando gebruiken:
git rebase -i <reference>
In veel situaties zal je referentie je main brach zijn. De optie -i start ‘interactive rebasing’. Dit geeft je de mogelijkheid om de commits aan te passen terwijl ze over worden gezet. Je kunt dit gebruiken om de commit historie op te schonen, wat één van de grote voordelen is van het gebruik van git rebase.
Het uitvoeren van het commando zal een lijst van mogelijke commits die verplaatst moeten worden in de editor laten zien. Dit geeft je volledige vrijheid om te veranderen hoe de commit geschiedenis eruit ziet. Je kunt ook commits mergen als je het pick commando verandert in fixup. Zodra je je wijzigingen opslaat, zal Git de rebase uitvoeren.
Over het algemeen gebruik je Git merge voor veel conflicten. Maar rebasen heeft ook veel voordelen. Terwijl merge eenvoudig te gebruiken is en je de context rondom je merge historie laat behouden, kan rebasen netter zijn omdat je je commit historie kunt vereenvoudigen tot één.
Desondanks moet je voorzichtiger zijn met rebasen, omdat de kans op fouten enorm is. Bovendien zou je deze techniek niet op publieke branches moeten gebruiken, aangezien rebasen alleen jouw repo zal beïnvloeden. Om de resulterende problemen op te lossen, moet je nog meer merges doen en zul je meerdere commits zien.
Tools die je helpen om een Git merge beter te beheren
Gezien de complexiteit rondom Git merge conflicten, zou je wel eens een helpende hand kunnen gebruiken. Er zijn genoeg tools beschikbaar om je te helpen een succesvolle merge uit te voeren, en als je Intellij IDEA gebruikt, heb je een ingebouwde methode met het Branches menu:
VSCode heeft ook soortgelijke functionaliteit in zijn gebruikersinterface (UI.) Oudere Atom gebruikers zullen merken dat Microsoft zijn fantastische Git integratie hier heeft voortgezet, compleet met de mogelijkheid om verbinding te maken met GitHub zonder verdere uitbreidingen of add-ons.
Je krijgt ook meer opties met het Command Palette. Dit is zelfs het geval in editors die voortbouwen op het open-source framework van VSCode, zoals Onivim2:
Het voordeel hier, zoals bij alle tools in deze lijst, is dat je de commandoregel niet nodig hebt om merges uit te voeren. Je moet meestal een bron en doel branch selecteren uit een drop-down menu en dan de editor de merge laten uitvoeren. Toch hoef je niet hands-off te werken. Je kunt de wijzigingen achteraf bekijken en dan de commit doen die je nodig hebt.
Een editor die een aparte grafische gebruikersinterface (GUI) biedt voor het werken met Git is Sublime Text. Als je deze editor gebruikt, zou Sublime Merge een ideale toevoeging aan je werkproces kunnen zijn:
Ongeacht je keuze voor een code editor, zal het vaak de mogelijkheid bieden om met Git te werken zonder de commandoregel te gebruiken. Dit is zelfs het geval met Vim en Neovim, met behulp van Tim Pope’s Git Fugitive plugin, die fantastisch en eenvoudig te gebruiken is.
Er zijn echter een paar speciale samenvoegprogramma’s van derden die zich alleen op deze taak richten.
Dedicated Git merge apps
Mergify is bijvoorbeeld een bedrijfsmatige manier om code te mergen die geïntegreerd is in je continuous integration/continuous delivery (CI/CD) pijplijn en workflow:
Sommige van de features hier helpen je om het bijwerken van je pull requests vóór het mergen te automatiseren, ze opnieuw te rangschikken op basis van prioriteit en ze ook in batches te mergen. Voor een open source oplossing kan Meld waardevol zijn:
De stabiele versie ondersteunt Windows en Linux en draait onder de GPL licentie. Dit geeft je basisfunctionaliteit om branches te vergelijken, merges te bewerken en meer. Je krijgt zelfs twee- of driewegs vergelijkingen en ondersteuning voor andere versiebeheersystemen zoals Subversion.
Samenvatting
Git is een essentiële tool om efficiënt samen te werken en codeveranderingen te beheren. Maar als meerdere developers aan dezelfde code werken, kunnen er conflicten ontstaan. Git merge strategieën zullen je helpen om deze conflicten op te lossen, en er zijn veel manieren om de klus te klaren. Voor complexere Git merge strategieën moet je je richten op geavanceerde tactieken.
Soms zijn ze eenvoudig, zoals het negeren van negatieve ruimtes of het doorzoeken van de zoeklogs. Je hoeft echter ook niet altijd de commandoregel te gebruiken. Er zijn genoeg apps om je te helpen, en je code editor zal vaak ook een ingebouwde interface gebruiken.
Als je Applicatie Hosting van hoge kwaliteit zoekt, dan kunnen wij je helpen. Onze cloud-based Applicatie Hosting diensten zorgen ervoor dat je full-stack app in een mum van tijd klaar is voor piekverkeer.
Welke van deze Git merge strategieën helpt jou uit de problemen? Laat het ons weten in het commentsectie hieronder!
Laat een reactie achter