Chapters ▾ 2nd Edition

4.1 Git på servern - Protokollen

Nu bör du kunna göra det mesta av de dagliga uppgifter som du använder Git till. För att kunna samarbeta i Git behöver du däremot ett fjärrkodförråd. Du kan tekniskt sett skicka och uppdatera ändringar direkt mellan personers egna kodförråd, men det avråds eftersom det är lätt att blanda ihop vad andra arbetar med om du inte är försiktig. Dessutom vill du att dina medarbetare ska kunna nå kodförrådet även när din dator är frånkopplad – därför är ett mer tillförlitligt gemensamt kodförråd ofta värdefullt. Det föredragna sättet att samarbeta är alltså att sätta upp ett mellanliggande kodförråd som ni båda har tillgång till och skicka och uppdatera därifrån.

Att köra en Git-server är ganska rakt på sak. Först väljer du vilka protokoll servern ska stödja. Det första avsnittet i kapitlet går igenom tillgängliga protokoll samt deras för- och nackdelar. Därefter beskriver vi typiska uppsättningar med dessa protokoll och hur du får servern att fungera. Till sist går vi igenom några leverantörsalternativ, om du inte vill lägga tid på att sätta upp och underhålla en egen server.

Om du inte vill köra en egen server kan du hoppa direkt till sista avsnittet för olika leverantörer, och sedan gå vidare till nästa kapitel där vi går igenom arbetet i en distribuerad versionshanteringsmiljö.

Ett fjärrkodförråd är oftast ett bart kodförråd – ett Git-kodförråd utan arbetskatalog. Eftersom kodförrådet bara fungerar som samarbetsnav finns det ingen poäng med en utlagd ögonblicksbild på disk; det är bara Git-data. I korthet är ett bart kodförråd innehållet i projektets .git-katalog och inget annat.

Protokollen

Git kan använda fyra olika protokoll för att överföra data: lokalt, HTTP, Secure Shell (SSH) och Git. Här går vi igenom vad de är och i vilka lägen du vill (eller inte vill) använda dem.

Lokala protokollet

Det mest grundläggande är lokala protokollet, där fjärrkodförrådet ligger i en annan katalog på samma värd. Det används ofta om hela teamet har tillgång till ett delat filsystem, till exempel en NFS-montering, eller i det mer ovanliga fallet att alla loggar in på samma dator. Det senare är inte idealiskt, eftersom alla kodförråd ligger på samma maskin och risken för en katastrofal förlust ökar.

Om du har ett delat filsystem kan du klona, skicka och dra från ett lokalt filbaserat kodförråd. För att klona ett sådant kodförråd, eller lägga till det som fjärrkodförråd i ett befintligt projekt, använder du sökvägen till kodförrådet som URL. Till exempel:

$ git clone /srv/git/project.git

Eller så här:

$ git clone file:///srv/git/project.git

Git beter sig lite olika om du uttryckligen anger file:// i början av URL:en. Om du bara anger sökvägen försöker Git använda hårdlänkar eller kopiera filerna direkt. Om du anger file:// startar Git de processer som normalt används över nätverk, vilket oftast är mindre effektivt. Huvudskälet till att använda file:// är antingen om du vill ha en ren kopia utan överflödiga referenser eller objekt – vanligen efter import från ett annat VCS eller liknande (se Git bakom kulisserna). Vi använder den vanliga sökvägen här eftersom det nästan alltid går snabbare.

För att lägga till ett lokalt kodförråd till ett befintligt Gitprojekt kan du göra så här:

$ git remote add local_proj /srv/git/project.git

Därefter kan du skicka och dra från det fjärrkodförrådet via namnet local_proj, precis som om det låg på nätet.

Fördelarna

Fördelarna med filbaserade kodförråd är att de är enkla och använder befintliga filrättigheter och nätverksåtkomst. Om du redan har ett delat filsystem som hela teamet når är det väldigt enkelt att sätta upp ett kodförråd. Du placerar ett bart kodförråd där alla har åtkomst och sätter läs- och skrivrättigheter som för vilken delad katalog som helst. Vi beskriver hur man exporterar ett bart kodförråd för detta i Konfigurera Git på en server.

Det är också ett bra sätt att snabbt hämta arbete från någon annans arbetskatalog. Om du och en kollega arbetar i samma projekt och hen vill att du ska titta på något, är git pull /home/john/project ofta enklare än att hen skickar upp till en server och att du sedan hämtar därifrån.

Nackdelarna

Nackdelarna är att delad åtkomst ofta är svårare att sätta upp och nå från flera platser än vanlig nätverksåtkomst. Om du vill skicka från din bärbara dator hemma måste du montera nätverksdisken, vilket kan vara både krångligt och långsamt.

Det är viktigt att nämna att detta inte nödvändigtvis är det snabbaste alternativet om du använder en delad nätverksdisk. Ett lokalt kodförråd är snabbt bara om du har snabb åtkomst till datan. Ett kodförråd på NFS är ofta långsammare än ett kodförråd över SSH på samma server, där Git kan arbeta från lokala diskar på varje system.

Slutligen skyddar inte protokollet kodförrådet mot oavsiktlig skada. Varje användare har full skalåtkomst till katalogen för fjärrkodförrådet, och inget hindrar dem från att ändra eller ta bort interna Gitfiler och korrumpera kodförrådet.

HTTP-protokollen

Git kan kommunicera över HTTP i två olika lägen. Före Git 1.6.6 fanns det bara ett sätt, som var enkelt och i regel enbart läsning. I version 1.6.6 kom ett smartare protokoll som låter Git förhandla dataöverföringen på ett sätt som liknar SSH. De senaste åren har det nya protokollet blivit populärt eftersom det är enklare för användaren och smartare i kommunikationen. Den nya varianten kallas ofta Smart HTTP och den äldre Dum HTTP. Vi börjar med Smart HTTP.

Smart HTTP

Smart HTTP fungerar mycket likt SSH- och Git-protokollen men går över vanliga HTTPS-portar och kan använda olika HTTP-autentiseringsmetoder. Det gör det ofta enklare för användaren, eftersom du kan använda användarnamn och lösenord i stället för att sätta upp SSH-nycklar.

Det har sannolikt blivit det vanligaste sättet att använda Git, eftersom det kan konfigureras för anonym åtkomst som git://, och samtidigt tillåta skickande med autentisering och kryptering som SSH. I stället för olika URL:er kan du använda en och samma. Om du försöker skicka och kodförrådet kräver autentisering (vilket det normalt bör göra) kan servern fråga efter användarnamn och lösenord. Detsamma gäller för läsåtkomst.

För tjänster som GitHub är URL:en du använder för att visa kodförrådet på webben (till exempel https://github.com/schacon/simplegit) densamma som du kan klona med och, om du har åtkomst, skicka till.

Dum HTTP

Om servern inte svarar med Smart HTTP-tjänst försöker Git-klienten falla tillbaka till Dum HTTP. Det dumma protokollet förväntar sig att det bara kodförrådet serveras som vanliga filer från webbservern. Det fina med Dum HTTP är enkelheten i att sätta upp det. I praktiken behöver du bara lägga ett bart kodförråd under dokumentroten för din HTTP-server och aktivera en särskild post-update-krok, och sedan är du klar (se Git‑krokar). Därefter kan alla som har åtkomst till webbservern klona kodförrådet. För att ge läsåtkomst över HTTP kan du göra så här:

$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update

Det är allt. post-update-kroken som följer med Git kör det nödvändiga kommandot (git update-server-info) så att hämtning och kloning över HTTP fungerar. Kommandot körs när du skickar upp till kodförrådet (kanske via SSH); därefter kan andra klona med:

$ git clone https://example.com/gitproject.git

I just detta exempel använder vi /var/www/htdocs, som är vanligt i Apache-uppsättningar, men du kan använda vilken statisk webbserver som helst – lägg bara det bara kodförrådet där. Gitdata serveras som vanliga statiska filer (se Git bakom kulisserna för detaljer).

I praktiken väljer du antingen en Smart HTTP-server med läs/skriv eller bara tillgång till filer via dum HTTP. Det är ovanligt att blanda dem.

Fördelarna

Vi fokuserar på Smart HTTP.

Enkelheten i att använda en enda URL för all åtkomst, och att servern bara frågar när autentisering behövs, gör det lätt för slutanvändaren. Att kunna autentisera med användarnamn och lösenord är också en stor fördel jämfört med SSH, eftersom användare inte behöver skapa SSH-nycklar lokalt och ladda upp sin publika nyckel för att kunna arbeta. För mindre erfarna användare eller system där SSH är mindre vanligt är detta en tydlig användbarhetsvinst. Det är dessutom ett snabbt och effektivt protokoll, i nivå med SSH.

Du kan också erbjuda kodförråd i läsläge över HTTPS, vilket betyder att du kan kryptera överföringen och i extremfallet kräva signerade SSL-certifikat av klienterna.

En annan fördel är att HTTP och HTTPS är så vanliga att företagsbrandväggar ofta redan tillåter trafik över dessa portar.

Nackdelarna

Git över HTTPS kan vara lite knepigare att konfigurera än SSH på vissa servrar. Utöver det har andra protokoll få fördelar jämfört med Smart HTTP när det gäller att förmedla Gitdata.

Om du använder HTTP för autentiserad uppsändning kan det ibland vara mer krångligt att ange inloggningsuppgifter än att använda SSH-nycklar. Det finns dock flera verktyg som mellanlagrar uppgifterna, till exempel Nyckelring på macOS och Credential Manager på Windows, vilket brukar göra det smidigt. Läs Lagring av inloggningsuppgifter för hur du sätter upp säker mellanlagring av HTTP‑lösenord.

SSH-protokollet

Ett vanligt transportprotokoll för Git vid egen drift är SSH. Det beror på att SSH-åtkomst redan är konfigurerad på många ställen – och om den inte är det är den enkel att sätta upp. SSH är dessutom ett autentiserat nätverksprotokoll och, eftersom det är så vanligt, relativt lätt att konfigurera och använda.

För att klona ett Git-kodförråd över SSH kan du ange en ssh://-URL:

$ git clone ssh://[user@]server/project.git

Eller så kan du använda den kortare scp-liknande syntaxen:

$ git clone [user@]server:project.git

I båda fallen antar Git att du autentiserar dig som den användare du är inloggad som, om du inte anger ett användarnamn.

Fördelarna

Fördelarna med SSH är många. För det första är SSH relativt enkelt att konfigurera – SSH-demoner är vanliga, många nätverksadministratörer har erfarenhet av dem och många distributioner levereras med dem eller verktyg för att hantera dem. För det andra är åtkomst över SSH säker: all dataöverföring är krypterad och autentiserad. Slutligen är SSH effektivt, precis som HTTPS, Git- och lokala protokollen, och gör datan så kompakt som möjligt innan överföring.

Nackdelarna

Nackdelen med SSH är att det inte stödjer anonym åtkomst. Om du använder SSH måste folk ha SSH-åtkomst till din maskin, även för läsning, vilket gör SSH olämpligt för öppna källkodsprojekt där folk bara vill klona och titta. Om du bara använder det inom företagets nät är SSH ofta allt du behöver. Om du vill ha anonym läsåtkomst och samtidigt använda SSH för uppsändning måste du erbjuda SSH för dig själv och något annat protokoll för andra att hämta med.

Git-protokollet

Till sist har vi Git-protokollet. Det är en särskild demon som följer med Git; den lyssnar på en dedikerad port (9418) och tillhandahåller en tjänst liknande SSH, men helt utan autentisering eller kryptering. För att ett kodförråd ska kunna erbjudas via Git-protokollet måste du skapa en git-daemon-export-ok-fil – annars serveras det inte – men förutom det finns det ingen säkerhet. Antingen är kodförrådet tillgängligt för alla att klona eller inte alls. Det innebär att man normalt inte skickar upp via detta protokoll. Du kan tillåta skrivåtkomst, men eftersom det saknar autentisering kan vem som helst på internet skicka om de hittar URL:en. Det är alltså ovanligt.

Fördelarna

Git-protokollet är ofta det snabbaste nätverksprotokollet. Om du har mycket trafik för ett publikt projekt eller ett mycket stort projekt som inte kräver autentisering för läsning är det troligt att du vill köra en Git-demon. Det använder samma dataöverföring som SSH men utan påslag från kryptering och autentisering.

Nackdelarna

På grund av avsaknaden av TLS eller annan kryptering kan kloning över git:// leda till godtycklig kodkörning och bör undvikas om du inte vet exakt vad du gör.

  • Om du kör git clone git://example.com/project.git kan en angripare som kontrollerar till exempel din router ändra kodförrådet du klonar och stoppa in skadlig kod. Om du sedan kompilerar eller kör koden kommer du att köra den skadliga koden. Att köra git clone http://example.com/project.git bör undvikas av samma skäl.

  • Att köra git clone https://example.com/project.git drabbas inte av samma problem (om inte angriparen kan tillhandahålla ett TLS-certifikat för example.com). git clone git\@example.com:project.git drabbas bara om du godkänner fel SSH-nyckelfingeravtryck.

Det finns heller ingen autentisering, alltså kan vem som helst klona kodförrådet (vilket ibland är precis det du vill). Det är också sannolikt det svåraste protokollet att sätta upp. Det måste köra sin egen demon, vilket kräver konfiguration med xinetd, systemd eller liknande, och det är inte alltid helt enkelt. Dessutom kräver det brandväggsöppning av port 9418, som inte är en standardport som företagsbrandväggar alltid släpper igenom. Bakom stora företagsbrandväggar är den porten ofta blockerad.