7.8 Git Tools - Mergen voor gevorderden

We kunnen nu kiezen. Als eerste, laten we bekijken hoe we uit deze situatie kunnen komen. Als je geen conflicten had verwacht en je wilt nu nog even niet met deze situatie te maken hebben, kan je eenvoudig de merge terugdraaien met git merge --abort.

De git merge --abort optie probeert de status terug te halen van voor je probeerde de merge te draaien. De enige gevallen waar dit misschien niet helemaal mogelijk is zou zijn als je ge-unstashde, ongecommitte wijzigingen in je werk-directory zou hebben staan toen je het aanriep, in alle andere gevallen zou het prima moeten werken.

Als je voor wat voor reden ook jezelf in een enorme bende weet te krijgen en je wilt gewoon opnieuw beginnen, kan je ook git reset --hard HEAD aanroepen of waar je ook naartoe wilt terugkeren. Onthoud: al het niet gecommitte werk gaat verloren, dus verzeker je ervan dat je hier geen onderhanden werk wilt hebben.

In dit specifieke geval hebben de conflicten met witruimtes te maken. We weten dit omdat dit geval eenvoudig is, maar het is ook redelijk eenvoudig te achterhalen in praktijksituaties als je naar een conflict kijkt, omdat elke regel is verwijderd aan de ene kant en weer aan de andere kant wordt toegevoegd. Standaard ziet Git al deze regels als gewijzigd en kan het dus de bestanden niet mergen.

De standaard merge strategie kan echter argumenten meekrijgen, en een aantal van deze gaan over het op een nette manier negeren van witruimte wijzigingen. Als je ziet dat je een groot aantal witruimte issues hebt in een merge, kan je deze eenvoudigweg afbreken en nogmaals uitvoeren, deze keer met -Xignore-all-space of -Xignore-space-change. De eerste optie negeert alle witruimte volledig bij het vergelijken van de regels, en de tweede beschouwt volgorderlijke witruimte karakters als gelijk.

Omdat in dit geval de eigenlijke bestandswijzigingen niet conflicteren, zal het negeren van de witruimte wijzigingen leiden tot een geslaagde merge.

Dit bespaart je veel werk als je iemand in je team hebt die regelmatig graag alles herformateert van spaties naar tabs of omgekeerd.

Hoewel Git het voorbewerken van witruimtes redelijk goed doet, zijn er andere soorten van wijzigingen waar Git misschien niet automatisch mee om kan gaan, maar zijn er oplossingen die met scripts gevonden kunnen worden. Als voorbeeld, stel dat Git de witruimte wijziging niet had kunnen verwerken en we hadden dit met de hand moeten doen.

Wat we echt zouden moeten doen is het bestand dat we proberen te mergen met een dos2unix programma bewerken voordat we de echte bestandsmerge uitvoeren. Dus, hoe zouden we dat doen?

Allereerst moeten we in de situatie van de merge conflict geraken. Dan willen we kopieën maken van mijn versie van het bestand, hun versie van het bestand (van de branch die we proberen te mergen) en de gezamelijke versie (van waar beide branches zijn afgesplitst). Daarna willen we een van de twee kanten verbeteren (die van hun of van ons) en dan de merge opnieuw proberen maar dan voor alleen deze ene bestand.

Het krijgen van de drie bestandversies is eigenlijk vrij makkelijk. Git bewaart al deze versies in de index onder “stages” die elk met getallen zijn geassocieerd. Stage 1 is de gezamelijke voorouder, stage 2 is jouw versie en stage 3 is van de MERGE_HEAD, de versie die je probeert te mergen (“theirs”).

Je kunt een kopie van elk van deze versie van het conflicterende bestand met het git show commando gecombineerd met een speciale syntax verkrijgen.

Als je iets dichter op het ijzer wilt werken, kan je ook het ls-files -u binnenwerk commando gebruiken om de echte SHA-1 nummers op te zoeken van de Git blobs voor elk van deze bestanden.

Het :1:hello.rb is gewoon een verkorte manier om de SHA-1 van de blob op te zoeken.

Nu we de inhoud van de drie stages in onze werk directory hebben, kunnen we handmatig die van hun opknappen om het witruimte probleem op te lossen en de bestanden opnieuw te mergen met het vrij onbekende git merge-file commando die precies dat doet.

We hebben op dit moment het bestand fijn gemerged. Sterker nog, dit werkt eigenlijk beter dan de ignore-space-change optie omdat dit echt de witruimte wijzigingen verbetert voor we mergen inplaats van ze gewoon te negeren. In de ignore-space-change merge, eindigen we uiteindelijk met een paar regels met DOS regel-einden, waardoor we dingen vermengen.

Als je voordat de commit wordt beeindigd een indruk wilt krijgen van wat daadwerkelijk gewijzigd is tussen de ene en de andere kant, kan je git diff vragen om wat in je werk directory zit te vergelijken met wat je van plan bent te committen als resultaat van de merge met elk van deze stages. Laten we ze eens allemaal bekijken.

Om het resultaat te vergelijken met wat je in je branch had voor de merge, met andere woorden om te zien wat de merge geïntroduceerd heeft, kan je git diff --ours aanroepen

Dus hier kunnen we makkelijk zien wat er in onze branch gebeurd is, wat we daadwerkelijk in dit bestand introduceren met deze merge is de wijziging in die ene regel.

Als we willen zien hoe het resultaat van de merge verschilt met wat er op hun kant stond, kan je git diff --theirs aanroepen. In deze en het volgende voorbeeld, moeten we -b gebruiken om de witruimtes te verwijderen omdat we het vergelijken met wat er in Git staat, niet onze opgeschoonde hello.their.rb bestand.

Als laatste kan je zien hoe het bestand is veranderd ten opzichte van beide kanten met git diff --base.

Op dit moment kunnen we het git clean commando gebruiken om de extra bestanden te verwijderen die we hebben gemaakt om de handmatige merge uit te voeren maar die we niet langer meer nodig hebben.

Misschien zijn we om de een of andere reden niet tevreden met de huidige oplossing, of misschien werkt het handmatig wijzigen van een of beide kanten nog steeds niet goed en moeten we meer van de omstandigheden te weten komen.

Laten we het voorbeeld een beetje veranderen. In dit voorbeeld hebben we twee langer doorlopende branches die elk een aantal commits hebben maar die, wanneer ze worden gemerged, een echt conflict op inhoud opleveren.

We hebben nu drie unieke commits die alleen in de master-branch aanwezig zijn en drie andere die op de mundo-branch zitten. Als we de mundo-branch willen mergen krijgen we een conflict.

We zouden willen zien wat de merge conflict is. Als we het bestand openen, zie we iets als dit:

Beide kanten van de merge hebben inhoud aan dit bestand toegevoegd, maar een aantal van de commits hebben het bestand op dezelfde plaats gewijzigd waardoor dit conflict optreedt.

Laten we een aantal instrumenten verkennen die je tot je beschikking hebt om te bepalen hoe dit conflict tot stand is gekomen. Misschien is het niet duidelijk hoe je dit conflict precies moet oplossen. Je hebt meer kennis van de context nodig.

Een handig instrument is git checkout met de --conflict optie. Dit zal het bestand opnieuw uitchecken en de merge conflict markeringen vervangen. Dit kan nuttig zijn als je de markeringen wilt verwijderen en de conflicten opnieuw wilt oplossen.

Je kunt aan --conflict of diff3 of merge doorgeven (de laatste is de standaard). Als je het diff3 doorgeeft zal Git iets andere soorten conflict markeringen gebruiken, waarbij je niet alleen de “ours” en “theirs” versies krijgt, maar ook de “base” versie inline waardoor je meer context krijgt.

Als we dat nu aanroepen, zal het bestand er nu zo uit zien:

Als dit formaat je bevalt, kan je dit als standaard instellen voor toekomstige merge conflicten door de merge.conflictstyle instelling op diff3 te zetten.

Het git checkout commando kan ook de opties --ours en --theirs verwerken, wat een ontzettend snelle manier kan zijn om gewoon een van de twee kanten te kiezen waarbij er gewoon niet gemerged zal worden.

Dit is in het bijzonder handig voor conflicten tussen binaire bestanden waar je gewoon een kant kiest, of waar je alleen bepaalde bestanden wilt mergen van een andere branch - je kunt de merge uitvoeren en dan bepaalde bestanden bekijken dan een of de andere kant voordat je commit.

Een ander nuttig instrument bij het oplossen van merge conflicten is git log. Dit kan je helpen bij het verkrijgen van inzicht in wat kan hebben bijgedragen tot het conflict. Een stukje historie nakijken om boven water te krijgen waarom twee ontwikkelingen dezelfde gebieden raakten kan soms erg behulpzaam zijn.

Om een complete lijst te krijgen van alle unieke commits die in elk van beide branches zitten en die betrokken zijn bij deze merge, kunnen we de “drievoudige punt” syntax gebruiken die we geleerd hebben in Drievoudige punt.

Dat is een mooie lijst van de in totaal zes betrokken commits, zowel als bij welke ontwikkellijn elke commit gedaan is.

We kunnen dit echter verder vereenvoudigen om ons een meer specifieke context te geven. Als we de --merge optie gebruiken bij git log, zal het alleen de commits tonen van beide kanten van de merge die een bestand raken dat op dit moment in een conflict betrokken is.

Als je het daarentegen met de -p optie aanroept, krijg je alleen de diffs met het bestand dat in een conflict betrokken is geraakt. Dit kan heel handig zijn bij het snel verkrijgen vn de context die je nodig hebt om te begrijpen waarom iets conflicteerd en hoe het beter overwogen op te lossen.

Omdat Git alle merge resultaten die succesvol zijn staget, zal het aanroepen van git diff terwijl je in een conflicterende merge status zit, je alleen laten zien wat op dit moment zich nog steeds in een conflicterende status bevindt. Dit kan heel handig zijn om te zien wat je nog steeds moet oplossen.

Als je git diff direct aanroept na een merge conflict, zal het je informatie geven in een nogal unieke diff uitvoer formaat.

Dit formaat heet “Gecombineerde Diff” (Combined Diff) en geeft je twee kolommen met gegevens naast elke regel. De eerste kolom laat je zien dat die regel anders is (toegevoegd of verwijderd) tuseen de “ours” branch en het bestand in je werk directory en de tweede kolom doet hetzelfde tussen de “theirs” branch en de kopie in je werk directory.

Dus in het voorbeeld kan je zien dat de <<<<<<< en >>>>>>> regels in de werk kopie zitten maar in geen van beide kanten van de merge. Dit is logisch omdat de merge tool ze daar in heeft gezet voor onze context, maar het wordt van ons verwacht dat we ze weghalen.

Als we het conflict oplossen en git diff nogmaals aanroepen, zien we hetzelfde, maar het is iets bruikbaarder.

Het laat ons zien dat “hola world” aan onze kant zat maar niet in de werk kopie, dat “hello mundo” aan hun kant stond maar niet in de werk kopie en uiteindelijk dat “hola mundo” in geen van beide kanten zat maar nu in de werk kopie staat. Dit kan nuttig zijn om na te kijken voordat de oplossing wordt gecommit.

Je kunt dit ook krijgen van de git log voor elke merge nadat deze is gedaan om achteraf te zien hoe iets was opgelost. Git zal deze uitvoer-vorm kiezen als je git show aanroept op een merge commit, of als je de --cc optie gebruikt bij een git log -p (die standaard alleen patces voor non-merge commits laat zien).

Als de ongewilde merge commit alleen bestaat in je lokale repository, is de eenvoudigste en beste oplossing om de branches dusdanig te verplaatsten dat ze wijzen naar waar je wilt hebben. In de meeste gevallen, als je de foutieve git merge opvolgt met git reset --hard HEAD~, zal dit de branch verwijzingen herstellen zodat ze er zo uit zien:

We hebben reset in Reset ontrafeld behandeld, dus het zou niet al te moeilijk uit te vinden wat hier gebeurt. Hier is een snelle opfrisser: reset --hard volgt normaalgesproken de volgende drie stappen:

Het nadeel van deze aanpak is dat het de historie herschrijft, wat problematisch kan zijn met een gedeelde repository. Bestudeer De gevaren van rebasen> om te zien wat er dan gebeuren kan; in het kort houdt het in dat als andere mensen de commits hebben die jij aan het herschrijven bent, je reset eigenlijk wilt vermijden. Deze aanpak zal ook niet werken als er andere commits gemaakt zijn sinds de merge; het verplaatsen van de referenties doet deze wijzigingen ook teniet.

Als het verplaatsen van de branch verwijzingen niet gaat werken voor je, geeft Git je de optie van het maken van een nieuwe commit die alle wijzigingen van een bestaande terugdraait. Git noemt deze operatie een “revert”, en in dit specifieke scenario zou je het als volgt aanroepen:

De -m 1 vlag geeft aan welke ouder de “hoofdlijn” (mainline) is en behouden moet blijven. Als je een merge naar HEAD begint (git merge topic), heeft de nieuwe commit twee ouders: de eerste is HEAD (C6), en de tweede is de punt van de branch die erin wordt gemerged (C4). In dit geval, willen we alle wijzigingen die zijn geïntroduceerd door het mergen van ouder #2 (C4) terugdraaien, terwijl we de alle inhoud van ouder #1 (C6) behouden.

De historie met de terugdraaiende commit ziet er zo uit:

De nieuwe commit ^M heeft precies dezelfde inhoud als C6, dus beginnende vanaf hier is het alsof de merge nooit heeft plaatsgevonden, behalve dat de commits die zijn ge-unmerged nog steeds in de geschiedenis van HEAD aanwezig zijn. Git zal in de war raken als je probeert topic weer in master te mergen:

Er is niets in topic wat niet al bereikbaar is vanaf master. Wat erger is, als je werk toevoegt aan topic en weer merged, zal Git alleen de wijzigingen meenemen sinds de teruggedraaide merge:

De beste manier om hiermee om te gaan is om de originele merge te ont-terugdraaien, omdat je nu de wijzigingen wilt doorvoeren die eruit waren verwijderd door ze terug te draaien, en dan een nieuwe merge commit te maken:

In dit voorbeeld, neutraliseren M en ^M elkaar. ^^M merget effectief de wijzigingen van C3 en C4, en C8 merged de wijzigingen van C7, dus nu is topic volledig gemerged.

Allereerst, is er een ander nuttig iets wat we met de normale “recursive” merge wijze kunnen doen. We hebben de ignore-all-space en ignore-space-change opties gezien die met een -X worden doorgegeven, maar we kunnen Git ook vertellen om de ene of de andere kant de voorkeur te geven als het een conflict bespeurt.

Standaard als Git een conflict ziet tussen twee branche die worden gemerged, zal het merge conflict markeringen in je code toevoegen en het bestand als conflicted bestempelen en je het laten oplossen. Als je de voorkeur hebt dat Git eenvoudigweg een bepaalde kant kiest en de andere kant negeert in plaats van je handmatig het conflict te laten oplossen kan je het merge commando een -Xours of -Xtheirs doorgeven.

Als Git dit ziet, zal het geen conflict markeringen invoegen. Alle verschillen die merge-baar zijn zal het mergen. Bij alle verschillen die conflicteren zal het simpelweg in het geheel de kant kiezen doe je opgeeft, ook bij binaire bestanden.

Als we terugkijken naar het “hello world” voorbeeld die we hiervoor gaven, kunnen we zien dat mergen in onze branch conflicten gaf.

Echter als we het gebruiken met -Xours of -Xtheirs gebeurt dit niet.

In dat geval, in plaats van conflict markeringen te krijgen in het bestand met “hello mundo” aan de ene en “hola world” aan de andere kant, zal het simpelweg “hola world” kiezen. Echter alle andere niet conflicterende wijzigingen in die branch zijn succesvol samengevoegd.

Deze optie kan ook aan het git merge-file commando die we eerder zagen worden doorgegeven door iets als git merge-file --ours aan te roepen voor individuele file merges.

Als je iets als die wilt doen maar Git niet eens wilt laten proberen wijzigingen van de andere kant te laten samenvoegen, is er een meer draconische optie, en dat is de “ours” merge strategie. Dit verschilt met de “ours” recursieve merge optie.

Dit zal feitelijk een nep merge uitvoeren. Het zal een nieuwe merge commit vastleggen met beide branches als ouders, maar het zal niet eens kijken naar de branch die je merget. Het zal eenvoudigweg de exacte code in je huidige branch vastleggen als het resultaat van de merge.

Je kunt zien dat er geen verschil is tussen de branch waar we op zaten en het resultaat van de merge.

Dit kan vaak handig zijn als je Git wilt laten denken dat een branch al ingemerget is wanneer je later een merge aan het doen bent. Bijvoorbeeld, stel dat je een “release” gemaakt hebt en daar wat werk aan gedaan hebt dat je later zeker naar je master-branche wilt mergen. In de tussentijd moet er een of andere bugfix op master moet teruggebracht (backported) worden naar je release-branch. Je kunt de bugfix branch in de release-branch mergen en dezelfde branch ook met merge -s ours in je master-branch mergen (zelfs als de fix daar al aanwezig is) zodat later als je de release-branch weer merget, er geen conflicten met de bugfix zijn.

Het idee achter de subtree merge is dat je twee projecten hebt, en een van de projecten verwijst naar een subdirectory van de ander en vice versa. Als je een subtree merge specificeert, is Git vaak slim genoeg om uit te vinden dat de ene een subtree van de ander en zal daarvoor passend mergen.

We zullen een voorbeeld doornemen van het toevoegen van een separaat project in een bestaand project en dan de code mergen van de tweede naar een subdirectory van de eerste.

Eerst zullen we de Rack applicatie aan ons project toevoegen. We gaan het Rack project als een remote referentie in ons project toevoegen en deze dan uitchecken in zijn eigen branch:

Nu hebben we de root van het Rack project in onze rack_branch-branch en ons eigen project in de master-branch. Als je eerst de ene en dan de andere uitcheckt, kan je zien dat ze verschillende project roots hebben:

Dit is een beetje een raar concept. Het is niet verplicht dat alle branches in je repository branches van hetzelfde project zijn. Het is niet iets wat vaak voorkomt, omdat het zelden behulpzaam is, maar het is relatief eenvoudig om branches te hebben die volledig verschillende histories hebben.

In dit geval willen we het Rack project in onze master-project binnenhalen (pull) als een subdirectory. We kunnen dat in Git doen met git read-tree. Je zult meer over read-tree en zijn vriendjes leren in Git Binnenwerk, maar neem voor nu aan dat het de root tree van een branch naar je huidige staging area en werk dirctory inleest. We zijn zojuist teruggeschakeld naar de master-branch, en we pullen de rack_branch-branch in de rack subdirectory van de master-branch van ons hoofdproject:

Als we committen, zal het lijken alsof we alle Rack bestanden onder die subdirectory hebben - alsof we ze vanuit een tarball gekopieerd hebben. Wat dit interessant maakt, is dat we relatief eenvoudig wijzigingen van de ene branch naar de andere kunnen mergen. Dus, als het Rack project wijzigt, kunnen we upstream wijzigingen binnenhalen door naar die branch over te schakelen en te pullen:

Daarna kunnen we die wijzigingen in onze master-branch mergen. Om de wijzigingen binnen te halen en de commit message alvast in te vullen, gebruik je de --squash optie zowel als de -Xsubtree optie van de recursieve merge strategy. (De recursieve strategie is hier de standaard, maar we voegen het voor de duidelijkheid toe).

All de wijzigingen van het Rack project zijn gemerged en klaar om lokaal te worden gecommit. Je kunt ook het tegenovergestelde doen - de wijzigingen in de rack subdirectory van je master branch maken en ze dan later naar je rack_branch-branch mergen om ze dan in te dienen bij de beheerders of ze stroomopwaarts te pushen.

Dit is een manier om een workflow te krijgen die lijkt op de submodule workflow zonder submodules te gebruiken (wat we in Submodules zullen behandelen). We kunnen in onze repository branches aanmaken met andere gerelateerde projecten en ze bij tijd en wijle subtree mergen in ons project. Dit is in sommige opzichten handig, bijvoorbeeld omdat alle code op een enkele plaats wordt gecommit. Het heeft echter ook nadelen in de zin dat het iets complexer is en gevoeliger voor fouten in het herintegreren van wijzigingen of abusievelijk een branch te pushen naar een niet gerelateerde repository.

Een ander gek iets is dat om een diff te krijgen tussen wat je in je rack subdirectory hebt en de code in je rack_branch-branch - om te zien of je ze moet mergen - kan je niet het normale diff commando gebruiken. In plaats daarvan moet je git diff-tree aanroepen met de branch waar het je mee wilt vergelijken:

Of, om wat in je rack subdirectory zit te vergelijken met wat de master-branch op de server was de laatste keer dat je gefetcht hebt kan je dit aanroepen