Een van de kernfuncties van Git is de mogelijkheid om meerdere versies van uw project. Vaak worden deze gebruikt voor kortetermijnvorken, genaamd “feature branches,” die worden samengevoegd tot master. Soms is het echter nodig om echt aparte branches te hebben, wat het moeilijker maakt om ze synchroon te houden.
Waarom verschillende branches onderhouden?
Gewoonlijk zijn branches van korte duur en bedoeld om terug te worden samengevoegd in de main release branch. In sommige gevallen is het echter nodig om volledig gescheiden takken te onderhouden. U kunt bijvoorbeeld branches hebben die zich op verschillende platforms of afhankelijkheden richten, met verschillende functies, of gewoon aparte release branches die u een tijdje in leven houdt.
Dit is dezelfde workflow met de meeste forks, en afhankelijk van de hoeveelheid en ernst van wijzigingen, kan het moeilijk zijn om synchroon te blijven met upstream. Als je twee branches grotendeels synchroon lopen, minus een paar commits, heb je een veel gemakkelijkere tijd om met conflicten om te gaan en dingen up-to-date te houden.
In de meeste gevallen moet je echter zoeken naar alternatieven voor het scheiden van branches, omdat het behoorlijk vervelend kan worden, vooral met samenvoegconflicten en al het extra testen. Als u bijvoorbeeld twee builds hebt die op verschillende platforms zijn gericht, hebben veel talen een buildconfiguratie en preprocessors die dat aankunnen. C# heeft #if NETVERSION, waarmee wijzigingen in de code mogelijk zijn op basis van het platform waarvoor het wordt gecompileerd.
Wat je reden ook is, dit is een geldige Git-workflow die veel mensen gebruiken.< /p>
Takken synchroon houden met rebasen
Er zijn in principe twee opties om dit aan te pakken. De eerste en meest gebruikelijke methode is rebasen, wat veel lijkt op samenvoegen, maar de takken volledig onafhankelijk maakt.
Advertentie
Je kunt Git-commits zien als een keten van veranderingen die teruggaat in de tijd, waarbij elke wijziging verwijst naar de vorige commit. Wanneer je een nieuwe vertakking aanmaakt, breekt deze af van de hoofdmastertak op een specifiek punt, de basis van de vertakking.
Rebasen is in feite het optillen van de hele feature branch, en het verplaatsen naar een nieuw tijdstip, waar het einde ervan naar een andere reeks commits wijst. Dit is vooral handig als de gevorkte branch maar een paar commits bevat, omdat de merge-conflicten dan gemakkelijker op te lossen zijn. In dit voorbeeld bevat het rebasen van deze branch de B- en C-commits, maar niet D en E, omdat het niet hoeft te rebasen op de HEAD van de branch.
Rebasen wordt echter vaak alleen voor lokale vertakkingen gebruikt en levert een paar problemen op bij gebruik met gedeelde vertakkingen. De commits bewegen niet echt; ze worden gekopieerd, wat resulteert in nieuwe commit ID's, waarbij de HEAD van de branch naar de nieuwe locatie wordt verplaatst.
Dit betekent dat de oude commits gestrand blijven. Omdat Git een gedecentraliseerd versiebeheersysteem is, kunnen je collega's niet-gepushte commits hebben die verwijzen naar die verwijderde commits. Rebasen moet iets zijn dat u met eventuele medewerkers coördineert, en als iemand conflicten heeft, moeten ze dit lokaal oplossen door die wijzigingen naar de juiste locatie te kopiëren.
Een branch rebasen is vrij eenvoudig. Je moet de feature branch uitchecken, alle wijzigingen van je afstandsbediening halen en dan rebase <branch> uitvoeren. om de feature-branch naar de doelbranch te verplaatsen.
git checkout feature git pull git rebase master Advertentie
Dit zal waarschijnlijk resulteren in merge-conflicten, die je zelf moet oplossen en vervolgens de wijzigingen moet vastleggen.
Hoewel de meeste dagelijkse Git-taken vrij gemakkelijk vanaf de opdrachtregel kunnen worden uitgevoerd, is rebasen van nature een vrij visuele bewerking, dus we raden aan om een GUI Git-client zoals Fork of GitKraken te gebruiken als je kunt. Dit toont u de vertakkingen en helpt u de rebase effectiever te plannen, en kan zelfs interactieve rebases uitvoeren.
Aangezien rebasen in principe elke commit van de feature branch toepast op een nieuwe locatie, hoef je ze niet allemaal op te nemen, en interactief rebasen kan commits laten vallen die je niet doet ;t nodig. Het is mogelijk om dit vanaf de opdrachtregel te doen, maar is logischer vanuit een GUI.
Ongewenste verplichtingen oplossen
Wat gebeurt er als je sommige commits niet wilt opnemen wanneer je rebaset? Als je commits op je feature branch hebt die je wilt uitsluiten bij het rebasen naar master, dan kun je een interactieve rebase doen. Dit zal de ongewenste commits bij het rebasen laten vallen, waardoor ze in feite uit de geschiedenis worden verwijderd.
Maar het is veel waarschijnlijker dat er commits zijn op de master branch die je liever niet op je feature branch hebt. Omdat rebasen de basis van de nieuwe branch naar master bepaalt, is er geen manier om die commits niet op te nemen.
Als er slechts een of twee commits zijn die je wilt om niet te hebben, kun je waarschijnlijk hoe dan ook rebasen, en het ofwel oplossen in het samenvoegconflict, het handmatig repareren, of gewoon de commit terugdraaien. Git heeft een “revert” commando dat de tegenovergestelde veranderingen toepast, in wezen een commit ongedaan maken en het maken alsof het nooit is gebeurd. Om het te gebruiken, voer je git log uit om de commit te vinden die je wilt terugzetten:
Kopieer vervolgens de SHA1-hash en zet de commit terug:
git revert 62ee517cc7c358eafbbffdebdde1b38dea92aa0f Advertentie
Hiermee wordt een “revert commit” op de feature branch.
Cherry-picking commits aan een andere branch
Het laatste scenario waar je tegenaan kunt lopen is als er maar een paar commits van de master zijn die je in een feature wilt hebben. Dit is gebruikelijk als je branches voor verschillende versies onderhoudt, omdat er vaak hotfixes en patches zijn die moeten worden toegepast op oudere versies van software.
Dit is echter de meest irritante methode om dingen te synchroniseren , want als je je branches niet op zijn minst enigszins synchroon houdt, is er een grote kans dat de commit die je wilt opnemen incompatibel is met de oudere branch.
Maar Git heeft wel tools om in wezen commits te kopiëren en in een andere branch te plakken. Deze actie wordt cherry-picking genoemd, omdat je een enkele commit uit de geschiedenis pakt en deze eruit plukt. Net als bij rebasen, creëert cherry-picking nieuwe gekopieerde commits, maar Git is meestal slim genoeg om het uit te zoeken, zelfs als je de branches later zou samenvoegen.
Om te kiezen, moet je de commit-ID pakken. Als je filiaalgeschiedenis ingewikkeld is, kun je git log uitvoeren met de optie –graph om een visuele weergave van je geschiedenis te krijgen, hoewel een GUI-client vooral handig is voor taken als deze.
git log –pretty=format :”%h %s” –graph
Zorg er dan voor dat u& #8217;re op de feature branch, en voer cherry-pick uit met de commit ID om het over te kopiëren.
git checkout feature git cherry-pick 1da76d3 Advertentie
Dit kan resulteren in conflicten, die je zal moeten oplossen.