7.13 Git-verktyg - Ersätt

Som vi har betonat tidigare är objekten i Gits objektdatabas oföränderliga, men Git erbjuder ett intressant sätt att låtsas ersätta objekt i databasen med andra objekt.

Kommandot replace låter dig ange ett objekt i Git och säga "varje gång du refererar till detta objekt, låtsas att det är ett annat objekt". Det här är oftast användbart för att ersätta en incheckning i din historik med en annan utan att behöva bygga om hela historiken med till exempel git filter-branch.

Till exempel, säg att du har en enorm kodhistorik och vill dela upp ditt kodförråd i en kort historik för nya utvecklare och en mycket längre och större historik för personer som är intresserade av datautvinning. Du kan ympa den ena historiken på den andra genom att "ersätta" den tidigaste incheckningen i den nya linjen med den senaste incheckningen i den äldre. Det är trevligt eftersom det betyder att du faktiskt inte behöver skriva om varje incheckning i den nya historiken, som du annars normalt måste göra för att sammanfoga dem (eftersom föräldraskapet påverkar SHA‑1‑värdena).

Låt oss prova. Vi tar ett befintligt kodförråd, delar upp det i två kodförråd, ett nyligt och ett historiskt, och ser sedan hur vi kan kombinera dem igen utan att ändra SHA‑1‑värdena i det nyare kodförrådet med hjälp av replace.

Vi använder ett enkelt kodförråd med fem enkla incheckningar:

Vi vill dela upp det här i två historiklinjer. Den ena linjen går från första incheckningen till den fjärde — det blir den historiska. Den andra linjen är bara incheckning fyra och fem — det blir den nyare historiken.

Att skapa den historiska historiken är enkelt; vi kan bara lägga en gren i historiken och sedan skicka den grenen till master i ett nytt fjärrkodförråd.

Nu kan vi skicka den nya history-grenen till master i vårt nya kodförråd:

Okej, så vår historik är publicerad. Nu är den svårare delen att kapa vår nyare historik så att den blir mindre. Vi behöver en överlappning så att vi kan ersätta en incheckning i den ena med en motsvarande incheckning i den andra, så vi kapar till bara incheckning fyra och fem (så att incheckning fyra överlappar).

Det är användbart att skapa en basincheckning med instruktioner om hur historiken kan byggas ut, så att andra utvecklare vet vad de ska göra om de stöter på den första incheckningen i den kapade historiken och behöver mer. Så här gör vi: vi skapar ett inledande incheckningsobjekt som baspunkt med instruktioner, och sedan ombaserar vi de återstående incheckningarna (fyra och fem) ovanpå den.

För att göra det måste vi välja en punkt att dela vid, vilket för oss är den tredje incheckningen, 9c68fdc i SHA‑språk. Så vår basincheckning kommer att baseras på det trädet. Vi kan skapa vår basincheckning med kommandot commit-tree, som bara tar ett träd och ger oss ett helt nytt, föräldralöst incheckningsobjekt tillbaka.

Okej, nu när vi har en basincheckning kan vi ombasera resten av vår historik ovanpå den med git rebase --onto. Argumentet --onto kommer att vara SHA‑1:an vi just fick tillbaka från commit-tree och ombaseringspunkten blir den tredje incheckningen (föräldern till den första incheckningen vi vill behålla, 9c68fdc).

Okej, så nu har vi skrivit om vår nyare historik ovanpå en kastad basincheckning som nu har instruktioner i sig om hur man återskapar hela historiken om man vill. Vi kan skicka den nya historiken till ett nytt projekt och nu när folk klonar det kodförrådet ser de bara de två senaste incheckningarna och sedan en basincheckning med instruktioner.

Nu byter vi roll till någon som klonar projektet för första gången och vill ha hela historiken. För att få historikdata efter att ha klonat det kapade kodförrådet behöver man lägga till ett andra fjärrkodförråd för det historiska kodförrådet och uppdatera:

Nu har medarbetaren sina nyare incheckningar i master‑grenen och de historiska incheckningarna i project-history/master.

För att kombinera dem kan du helt enkelt kalla git replace med incheckningen du vill ersätta och sedan incheckningen du vill ersätta den med. Vi vill alltså ersätta den "fjärde" incheckningen i master‑grenen med den "fjärde" incheckningen i project-history/master:

Om du nu tittar på historiken i master‑grenen ser det ut att vara så här:

Coolt, eller hur? Utan att behöva ändra alla SHA‑1‑värden uppströms kunde vi ersätta en incheckning i historiken med en helt annan incheckning och alla normala verktyg (bisect, blame, osv.) kommer att fungera som vi förväntar oss.

Intressant nog visar den fortfarande 81a708d som SHA‑1, även om den i själva verket använder data från c6e1e95‑incheckningen som vi ersatte den med. Även om du kör ett kommando som cat-file kommer det att visa dig de ersatta uppgifterna:

Kom ihåg att den faktiska föräldern till 81a708d var vår platshållarincheckning (622e88e), inte 9c68fdce som det står här.

En annan intressant sak är att denna data sparas i våra referenser:

Det betyder att det är lätt att dela vår ersättning med andra, eftersom vi kan skicka detta till vår server och andra kan enkelt ladda ner den. Det är inte så hjälpsamt i det historikympningsscenario vi har gått igenom här (eftersom alla ändå skulle uppdatera båda historikerna, så varför separera dem?) men det kan vara användbart i andra sammanhang.