7.13 Git Tools - Vervangen

Zoals we eerder hebben benadrukt zijn de objecten in de database van Git onwijzigbaar, maar Git heeft een interessante manier om te doen alsof je objecten in de database vervangt met andere objecten.

Het replace commando laat je een object in Git opgeven en te zeggen dat "elke keer als je dit object ziet, doe alsof het dit een ander object is". Dit is het nuttigst voor het vervangen van een commit in je historie met een andere zonder de gehele historie te vervangen met, laten we zeggen, git filter-branch.

Bijvoorbeeld, stel dat je een enorme code historie hebt en je wilt je repository opsplitsen in een korte historie voor nieuwe ontwikkelaars en een veel langere en grotere historie voor mensen die geïnteresseerd zijn in het graven in gegevens (data mining). Je kunt de ene historie op de andere enten door de vroegste commit in de nieuwe lijn met de laatste commit van de oude lijn te "vervangen". Dit is prettig omdat het betekent dat je niet echt alle commits in de nieuwe historie hoeft te herschrijven, wat je normaalgesproken wel zou moeten doen om ze samen te voegen (omdat de voorouderschap de SHA-1’s beïnvloedt).

Laten we dat eens uitproberen. Laten we een bestaande repository nemen, en deze in twee repositories splitsen, een recente en een historische, en laten we dan kijken hoe we ze kunnen herschikken zonder de SHA-1 waarden van de recente repository te wijzigen met behulp van replace.

We zullen een eenvoudige repository met vijf simpele commits gebruiken:

We willen deze opdelen in twee historische lijnen. Een lijn gaat van commit een tot commit vier - dat zal de historische worden. De tweede lijn zal alleen commits vier en vijf zijn - dat is dan de recente historie.

Nu, de historische historie maken is eenvoudig, we kunnen gewoon een branch in de geschiedenis zetten en dan die branch naar de master branch pushen van een nieuwe remote repository.

Nu kunnen we de nieuwe history-branch naar de master-branch van onze nieuwe repository pushen:

Goed, onze historie is nu gepubliceerd. Nu is het moeilijkere gedeelte het terugsnoeien van onze recente historie zodat deze kleiner wordt. We moeten een overlapping maken op zo’n manier dat we een commit kunnen vervangen in een repository die een gelijke commit heeft, dus we gaan deze afkappen tot alleen commits vier en vijf (dus de vierde commit overlapt).

Het is in dit geval handig om een basis commit te maken die instructies bevat hoe de historie uit te breiden, zodat andere ontwikkelaars weten wat te doen als ze de eerste commit in de afgekapte historie tegenkomen en meer nodig hebben. Dus wat we hier gaan doen is een initieel commit object maken als onze basis en daar instructies in zetten, dan rebasen we de overige commits (vier en vijf) daar bovenop.

Om dat te doen, moeten we een punt kiezen om af te splitsen, wat voor ons de derde commit is, welke 9c68fdc in SHA-spraak is. Dus onze basis commit zal van die tree af worden getakt. We kunnen onze basis commit maken met het commit-tree commando, wat gewoon een tree neemt en ons een SHA-1 teuggeeft van een gloednieuw, ouderloos commit object.

Goed, nu we dus een basis commit hebben, kunnen we de rest van onze historie hier boven op rebasen met git rebase --onto. Het --onto argument zal de SHA-1 zijn die we zojuist terugkregen van commit-tree en het rebase punt zal de derde commit zijn (de ouder van de eerste commit die we willen bewaren: 9c68fdc):

Mooi, dus we hebben onze recente historie herschreven bovenop een weggooi basis commit die nu onze instructies bevat hoe de gehele historie weer te herbouwen als we dat zouden willen. We kunnen die nieuwe historie op een nieuw project pushen en nu, als mensen die repository klonen, zullen ze alleen de meest recente twee commits zien en dan een basis commit met instructies.

Laten we de rollen nu omdraaien naar iemand die het project voor het eerst kloont en die de hele historie wil hebben. Om de historische gegevens na het klonen van deze gesnoeide repository te krijgen, moet je een tweede remote toevoegen voor de historische repository en dan fetchen:

Nu zal de medewerker hun recente commits in de master-branch hebben en de historische commits in de project-history/master-branch.

Om deze te combineren, kan je simpelweg git replace aanroepen met de commit die je wilt vervangen en dan de commit waarmee je het wilt vervangen. Dus we willen de "fourth" commit in de master branch met de "fourth" commit in de project-history/master-branch vervangen:

Als je nu naar de historie van de master-branch kijkt, lijkt het er zo uit te zien:

Gaaf, toch? Zonder alle SHA-1 stroomopwaarts te hoeven vervangen, waren we toch in staat om een commit in onze history te vervangen met een compleet andere commit en alle normale instrumenten (bisect, blame, etc.) blijven werken zoals we van ze mogen verwachten.

Interessant genoeg, blijf het nog steeds 81a708d als de SHA-1 laten zien, zelfs als het in werkelijkheid de gegevens van de c6e1e95 commit gebruikt waar we het mee hebben vervangen. Zelfs als je een commando als cat-file aanroept, zal het je de vervangen gegevens tonen:

Onthoud dat de echte ouder van 81a708d onze plaatsvervangende commit was (622e88e), niet 9c68fdce zoals hier vermeld staat.

Het andere interessante is dat deze gegevens in onze referenties opgeslagen zijn:

Dit houdt in dat het eenvoudig is om onze vervanging met anderen te delen, omdat we deze naar onze server kunnen pushen en andere mensen het eenvoudig kunnen downloaden. Dit is niet zo nuttig in het scenario van historie-enten welke we hier nu behandeld hebben (als iedereen toch beide histories zou gaan downloaden, waarom zouden we ze dan gaan splitsen) maar het kan handig zijn in andere omstandigheden.