9.1 Git och andra system - Git som klient

Grundkommandot i Git för alla Subversion‑bryggkommandon är git svn. Det har ganska många underkommandon, så vi visar de vanligaste medan vi går igenom några enkla arbetsflöden.

Det är viktigt att notera att när du använder git svn så interagerar du med Subversion, som fungerar på ett helt annat sätt än Git. Även om du kan göra lokala grenar och sammanslagningar är det generellt bäst att hålla historiken så linjär som möjligt genom att ombasera ditt arbete och undvika att samtidigt arbeta mot ett Git‑fjärrkodförråd.

Skriv inte om historiken och försök skicka på nytt, och skicka inte upp till ett parallellt Git‑kodförråd för att samarbeta med andra Git‑utvecklare samtidigt. Subversion kan bara ha en enda linjär historik, och det är mycket lätt att förvirra den. Om du arbetar i ett team och några använder SVN medan andra använder Git, se till att alla använder SVN‑servern för samarbete – då blir livet enklare.

För att demonstrera den här funktionaliteten behöver du ett typiskt SVN‑kodförråd som du har skrivåtkomst till. Om du vill följa exemplen måste du skapa en skrivbar kopia av ett SVN‑testkodförråd. För att göra det enkelt kan du använda ett verktyg som heter svnsync som följer med Subversion.

För att kunna följa med behöver du först skapa ett nytt lokalt Subversion‑kodförråd:

Sedan behöver du tillåta att alla användare kan ändra revprops – det enkla sättet är att lägga till ett pre-revprop-change‑skript som alltid avslutas med 0:

Nu kan du synka projektet till din lokala maskin genom att anropa svnsync init med käll- och mål‑kodförråd.

Detta sätter upp egenskaperna för att köra synken. Därefter kan du klona koden genom att köra:

Även om den här operationen ofta bara tar några minuter tar processen nästan en timme om du försöker kopiera det ursprungliga kodförrådet till ett annat fjärrkodförråd i stället för ett lokalt, även om det finns färre än 100 incheckningar. Subversion måste klona en revision i taget och sedan skicka tillbaka den till ett annat kodförråd – det är extremt ineffektivt, men det är det enda enkla sättet att göra detta.

Nu när du har ett Subversion‑kodförråd som du har skrivåtkomst till kan du gå igenom ett typiskt arbetsflöde. Du börjar med kommandot git svn clone, som importerar ett helt Subversion‑kodförråd till ett lokalt Git‑kodförråd. Kom ihåg att om du importerar från ett riktigt driftsatt Subversion‑kodförråd ska du ersätta file\:///tmp/test-svn här med webbadressen till ditt Subversion‑kodförråd:

Det här motsvarar att först köra git svn init och sedan git svn fetch på den angivna webbadressen. Det kan ta en stund. Om till exempel testprojektet bara har runt 75 incheckningar och kodbasen inte är så stor måste Git ändå ta ut varje version, en i taget, och checka in den individuellt. För ett projekt med hundratals eller tusentals incheckningar kan detta bokstavligen ta timmar eller till och med dagar att bli klart.

Delen -T trunk -b branches -t tags talar om för Git att detta Subversion‑kodförråd följer de grundläggande konventionerna för grenar och taggar. Om du namnger din trunk, dina grenar eller taggar annorlunda kan du ändra dessa alternativ. Eftersom detta är så vanligt kan du ersätta hela delen med -s, som betyder standardlayout och innebär alla dessa alternativ. Följande kommando är likvärdigt:

Nu bör du ha ett giltigt Git‑kodförråd som har importerat dina grenar och taggar:

Notera hur det här verktyget hanterar Subversion‑taggar som fjärrreferenser. Låt oss titta närmare med Git‑lågnivåkommandot show-ref:

Git gör inte detta när det klonar från en Git‑server; så här ser ett kodförråd med taggar ut efter en ny klon:

Git uppdaterar taggarna direkt till refs/tags i stället för att behandla dem som fjärrgrenar.

Nu när du har en arbetskatalog kan du göra lite arbete i projektet och skicka tillbaka dina incheckningar uppströms, där Git i praktiken fungerar som SVN‑klient. Om du redigerar en av filerna och checkar in den har du en incheckning som finns lokalt i Git men inte på Subversion‑servern:

Därefter behöver du skicka ändringen. Lägg märke till hur detta förändrar sättet du arbetar med Subversion – du kan göra flera incheckningar utan uppkoppling och sedan skicka dem allihop till Subversion‑servern på en gång. För att skicka till en Subversion‑server kör du kommandot git svn dcommit:

Det här tar alla dina lokala incheckningar ovanpå Subversion-koden, gör en Subversion-incheckning för var och en och skriver sedan om de lokala Git-incheckningarna med en unik identifierare. Det är viktigt, eftersom alla SHA-1-kontrollsummor för dina incheckningar ändras. Delvis av den anledningen är det ingen bra idé att arbeta samtidigt med Git‑baserade fjärrversioner av dina projekt parallellt med en Subversion‑server. Om du tittar på den senaste incheckningen kan du se den nya git-svn-id som lagts till:

Notera att SHA‑1‑kontrollsumman som ursprungligen började med 4af61fd när du checkade in nu börjar med 95e0222. Om du vill skicka till både en Git‑server och en Subversion‑server måste du skicka (dcommit) till Subversion‑servern först, eftersom den åtgärden ändrar din incheckningsdata.

Om du arbetar med andra utvecklare kommer någon av er förr eller senare att skicka, och sedan kommer den andre att försöka skicka en ändring som står i konflikt. Den ändringen blir nekad tills du sammanfogar deras arbete. I git svn ser det ut så här:

För att lösa situationen kan du köra git svn rebase, som uppdaterar ner alla ändringar på servern som du ännu inte har och ombaserar ditt arbete ovanpå det som ligger på servern:

Nu ligger allt ditt arbete ovanpå det som finns på Subversion‑servern, så du kan dcommit utan problem:

Observera att till skillnad från Git, som kräver att du sammanfogar uppströmsarbete du ännu inte har lokalt innan du kan skicka, tvingar git svn dig att göra det bara om ändringarna står i konflikt (ungefär som Subversion fungerar). Om någon annan skickar upp en ändring i en fil och du sedan skickar upp en ändring i en annan fil fungerar din dcommit fint:

Det är viktigt att komma ihåg, eftersom resultatet kan bli ett projekttillstånd som inte fanns på någon av era datorer vid uppskickning. Om ändringarna är inkompatibla men inte i konflikt kan du få problem som är svåra att felsöka. Till skillnad från en Git-server kan du i Git testa hela tillståndet lokalt innan publicering, medan du i SVN inte kan vara säker på att tillstånden före och efter incheckning är identiska.

Du bör också köra detta kommando för att uppdatera ändringar från Subversion‑servern, även om du inte är redo att checka in själv. Du kan köra git svn fetch för att uppdatera den nya datan, men git svn rebase gör uppdateringen och uppdaterar sedan dina lokala incheckningar.

Att köra git svn rebase då och då ser till att din kod alltid är uppdaterad. Du måste dock se till att din arbetskatalog är ren när du kör det. Om du har lokala ändringar måste du antingen lägga undan arbetet med git stash eller tillfälligt checka in det innan du kör git svn rebase – annars stoppar kommandot om det ser att ombaseringen leder till en sammanslagningskonflikt.

När du har blivit bekväm med ett Git‑arbetsflöde skapar du sannolikt ämnesgrenar, gör arbete på dem och sammanfogar dem sedan. Om du skickar upp till en Subversion‑server via git svn kan du vilja ombasera ditt arbete till en enda gren varje gång i stället för att sammanfoga grenar. Anledningen till att föredra ombasering är att Subversion har en linjär historik och inte hanterar sammanslagningar som Git gör, så git svn följer bara den första föräldern när den konverterar ögonblicksbilderna till Subversion‑incheckningar.

Anta att din historik ser ut så här: du skapade en gren experiment, gjorde två incheckningar och sammanfogade dem sedan tillbaka till master. När du kör dcommit ser du utdata som detta:

Att köra dcommit på en gren med sammanfogad historik fungerar, förutom att när du tittar på historiken i ditt Git‑projekt har den inte skrivit om någon av incheckningarna du gjorde på grenen experiment – i stället dyker alla dessa ändringar upp i SVN‑versionen av den enda sammanslagningsincheckningen.

När någon annan klonar det arbetet ser de bara sammanslagningsincheckningen med allt arbete ihoptryckt i den, som om du körde git merge --squash; de ser inte incheckningsdata om var det kom ifrån eller när det incheckades.

Grenar i Subversion är inte samma sak som grenar i Git; om du kan undvika att använda det så mycket är det sannolikt bäst. Du kan dock skapa och checka in på grenar i Subversion med git svn.

För att skapa en ny gren i Subversion kör du git svn branch [new-branch]:

Det här motsvarar Subversion‑kommandot svn copy trunk branches/opera och arbetar mot Subversion‑servern. Det är viktigt att notera att det inte växlar till den grenen; om du checkar in nu kommer incheckningen att hamna i trunk på servern, inte opera.

Git räknar ut vilken gren dina dcommit går till genom att leta efter toppen på någon av dina Subversion‑grenar i historiken – du bör bara ha en, och det ska vara den senaste med ett git-svn-id i din nuvarande grenhistorik.

Om du vill arbeta på mer än en gren samtidigt kan du sätta upp lokala grenar för att dcommit till specifika Subversion‑grenar genom att starta dem på den importerade Subversion‑incheckningen för den grenen. Om du vill ha en gren opera som du kan arbeta på separat kan du köra:

Om du nu vill sammanfoga grenen opera till trunk (din master‑gren) kan du göra det med en vanlig git merge. Men du behöver ange ett beskrivande incheckningsmeddelande (via -m), annars kommer sammanslagningen att säga “Merge branch opera” i stället för något användbart.

Kom ihåg att även om du använder git merge för den här operationen, och sammanslagningen sannolikt blir mycket enklare än den skulle vara i Subversion (eftersom Git automatiskt hittar rätt sammanslagningsbas åt dig), så är detta inte en normal Git‑sammanslagning. Du måste skicka datan till en Subversion‑server som inte kan hantera en incheckning som spårar mer än en förälder; så efter att du har skickat upp den ser den ut som en enda incheckning som tryckt ihop allt arbete från en annan gren i en enda incheckning. Efter att du har sammanfogat en gren till en annan kan du inte enkelt gå tillbaka och fortsätta arbeta på den grenen, som du normalt kan i Git. Kommandot dcommit som du kör raderar all information som säger vilken gren som sammanfogades in, så efterföljande beräkningar av sammanslagningsbaser blir fel – dcommit får resultatet av din git merge att se ut som om du körde git merge --squash. Tyvärr finns det inget bra sätt att undvika denna situation – Subversion kan inte lagra denna information, så du kommer alltid att vara begränsad av dess begränsningar medan du använder den som server. För att undvika problem bör du ta bort den lokala grenen (i detta fall opera) efter att du har sammanfogat den till trunk.

Verktygsuppsättningen git svn ger ett antal kommandon som underlättar övergången till Git genom att erbjuda funktionalitet som liknar det du hade i Subversion. Här är några kommandon som ger dig det Subversion brukade ge.

Verktygen i git svn är användbara om du sitter fast med en Subversion‑server eller på annat sätt befinner dig i en utvecklingsmiljö som kräver en Subversion‑server. Du bör dock se det som en stympad Git, annars stöter du på översättningsproblem som kan förvirra dig och dina medarbetare. För att undvika problem, försök att följa dessa riktlinjer:

Om du följer dessa riktlinjer kan arbete mot en Subversion‑server bli mer uthärdligt. Men om det är möjligt att flytta till en riktig Git‑server ger det teamet mycket mer.

Först behöver du installera git-remote-hg. Det innebär i praktiken att lägga filen någonstans i din sökväg, till exempel så här:

…förutsatt att ~/bin ligger i din $PATH. Git‑fjärrkodförråd-hg har också ett beroende: mercurial‑biblioteket för Python. Om du har Python installerat räcker det med:

Om du inte har Python installerat, besök https://www.python.org/ och skaffa det först.

Det sista du behöver är Mercurial‑klienten. Gå till https://www.mercurial-scm.org/ och installera den om du inte redan har gjort det.

Nu är du redo. Allt du behöver är ett Mercurial‑kodförråd som du kan skicka till. Lyckligtvis kan varje Mercurial‑kodförråd fungera så, så vi använder bara "hello world"‑kodförrådet som alla använder för att lära sig Mercurial:

Nu när vi har ett lämpligt “serversidan”‑kodförråd kan vi gå igenom ett typiskt arbetsflöde. Som du kommer att se är de här två systemen tillräckligt lika för att det inte ska bli särskilt mycket friktion.

Som alltid med Git börjar vi med att klona:

Du kommer att märka att arbete med ett Mercurial‑kodförråd använder det vanliga kommandot git clone. Det beror på att git-remote-hg arbetar på ganska låg nivå och använder en mekanism som liknar hur Gits HTTP/S‑protokoll är implementerat (fjärrhjälpare). Eftersom Git och Mercurial båda är utformade för att varje klient ska ha en fullständig kopia av kodförrådshistoriken gör kommandot en full klon, inklusive hela projektets historik, och gör det ganska snabbt.

Kommandot log visar två incheckningar, där den senaste pekas ut av en hel svärm av referenser. Det visar sig att några av dem inte finns där. Låt oss titta på vad som verkligen ligger i .git‑katalogen:

Git‑fjärrkodförråd-hg försöker göra saker mer idiomatiska för Git, men under huven hanterar det den konceptuella mappningen mellan två något olika system. Katalogen refs/hg är där de faktiska fjärrreferenserna lagras. Till exempel är refs/hg/origin/branches/default en Git‑reffil som innehåller SHA‑1:an som börjar med “ac7955c”, vilket är incheckningen som master pekar på. Så katalogen refs/hg är lite som ett låtsas‑refs/remotes/origin, men med den extra distinktionen mellan bokmärken och grenar.

Filen notes/hg är startpunkten för hur git-remote-hg mappar Git‑incheckningshashar till Mercurial‑ändringsuppsättnings‑ID:n. Låt oss utforska lite:

Så refs/notes/hg pekar på ett träd, som i Gits objektdatabas är en lista över andra objekt med namn. git ls-tree skriver ut läge, typ, objekthash och filnamn för objekt i ett träd. När vi gräver oss ner till ett av trädobjekten hittar vi inuti en blob som heter “ac9117f” (SHA‑1‑hashen för incheckningen som master pekar på), med innehållet “0a04b98” (vilket är ID:t för Mercurial‑ändringsuppsättningen längst fram på grenen default).

Den goda nyheten är att vi för det mesta inte behöver bekymra oss om allt detta. Det typiska arbetsflödet skiljer sig inte särskilt mycket från att arbeta med ett Git‑fjärrkodförråd.

Det finns en sak till vi bör ta hand om innan vi fortsätter: ignoreringsregler. Mercurial och Git använder en mycket liknande mekanism för detta, men du vill sannolikt inte checka in en .gitignore‑fil i ett Mercurial‑kodförråd. Lyckligtvis har Git ett sätt att ignorera filer lokalt i ett kodförråd på disk, och Mercurial‑formatet är kompatibelt med Git, så du behöver bara kopiera det:

Filen .git/info/exclude fungerar precis som en .gitignore, men ingår inte i incheckningar.

Låt oss anta att vi har gjort lite arbete och gjort några incheckningar på grenen master, och att du är redo att skicka det till fjärrkodförrådet. Så här ser vårt kodförråd ut just nu:

Vår gren master ligger två incheckningar före origin/master, men de två incheckningarna finns bara på vår lokala maskin. Låt oss se om någon annan har gjort viktigt arbete samtidigt:

Eftersom vi använde flaggan --all ser vi “notes”‑referenserna som används internt av git-remote-hg, men vi kan ignorera dem. Resten är vad vi förväntade oss; origin/master har gått framåt med en incheckning, och vår historik har nu divergerat. Till skillnad från de andra systemen vi arbetar med i det här kapitlet klarar Mercurial av sammanslagningar, så vi behöver inte göra något avancerat.

Perfekt. Vi kör testerna och allt går igenom, så vi är redo att dela vårt arbete med resten av teamet:

Det var allt! Om du tittar i Mercurial‑kodförrådet ser du att detta gjorde det vi förväntade oss:

Ändringsuppsättningen med nummer 2 skapades av Mercurial, och ändringsuppsättningarna 3 och 4 skapades av git-remote-hg genom att skicka incheckningar som gjorts i Git.

Git har bara en sorts gren: en referens som flyttar sig när incheckningar görs. I Mercurial kallas den här typen av referens för ett “bokmärke” och det fungerar på ungefär samma sätt som en Git‑gren.

Mercurials begrepp “gren” är mer tungviktigt. Grenen som en ändringsuppsättning görs på registreras tillsammans med ändringsuppsättningen, vilket betyder att den alltid kommer att finnas i kodförrådshistoriken. Här är ett exempel på en incheckning som gjordes på grenen develop:

Notera raden som börjar med “branch”. Git kan egentligen inte replikera detta (och behöver inte heller; båda typerna av grenar kan representeras som en Git‑referens), men git-remote-hg behöver förstå skillnaden eftersom Mercurial gör det.

Att skapa Mercurial‑bokmärken är lika enkelt som att skapa Git‑grenar. På Git‑sidan:

Det är allt som behövs. På Mercurial‑sidan ser det ut så här:

Notera den nya taggen [featureA] på revision 5. De fungerar exakt som Git‑grenar på Git‑sidan, med ett undantag: du kan inte ta bort ett bokmärke från Git‑sidan (detta är en begränsning i fjärrhjälparen).

Du kan också arbeta på en “tungviktig” Mercurial‑gren: lägg bara en gren i namnrymden branches:

Så här ser det ut på Mercurial‑sidan:

Grennamnet “permanent” registrerades tillsammans med ändringsuppsättningen markerad 7.

Från Git‑sidan är arbetet med båda dessa grenstilar detsamma: växla bara till, checka in, uppdatera, sammanfoga, dra och skicka som du brukar. En sak du bör känna till är att Mercurial inte stödjer omskrivning av historik, bara tillägg. Så här ser vårt Mercurial‑kodförråd ut efter en interaktiv ombasering och en tvångsuppskickning:

Ändringsuppsättningarna 8, 9 och 10 har skapats och hör till grenen permanent, men de gamla ändringsuppsättningarna finns fortfarande kvar. Det kan vara mycket förvirrande för dina teamkamrater som använder Mercurial, så försök undvika det.

Git och Mercurial är tillräckligt lika för att arbete över gränsen ska vara ganska smärtfritt. Om du undviker att ändra historik som har lämnat din maskin (som generellt rekommenderas) kanske du inte ens märker att den andra änden är Mercurial.

Perforce tillhandahåller en produkt som heter Git Fusion (tillgänglig på https://web.archive.org/web/20180101000000/https://www.perforce.com/manuals/git-fusion/), som synkroniserar en Perforce‑server med Git‑kodförråd på serversidan.

Git-p4 är en tvåvägsbrygga mellan Git och Perforce. Den körs helt och hållet inne i ditt Git‑kodförråd, så du behöver ingen särskild åtkomst till Perforce‑servern (förutom användaruppgifter förstås). Git-p4 är inte lika flexibel eller komplett som Git Fusion, men den låter dig göra det mesta du vill utan att behöva ingripa i servermiljön.

Git-p4 gör det möjligt att använda ett Git‑arbetsflöde med en Perforce‑server, och det fungerar ganska bra. Det är dock viktigt att komma ihåg att Perforce styr källan och att du bara använder Git för att arbeta lokalt. Var mycket försiktig med att dela Git‑incheckningar; om du har ett fjärrkodförråd som andra använder, skicka inte in några incheckningar som inte redan har skickats in till Perforce‑servern.

Om du vill blanda användningen av Perforce och Git fritt som klienter för versionshantering, och du kan övertyga serveradministratören att installera det, gör Git Fusion Git till en förstklassig versionshanteringsklient för en Perforce‑server.