Git
Chapters ▾ 2nd Edition

4.1 Git på servern - Protokollen

Nu bör du kunna göra det mesta av dina dagliga arbetsuppgifter som kräver Git. För att kunna samarbeta med andra i Git, behöver du ett fjärrepo dit du kan skicka ditt arbete. Fastän du rent tekniskt kan skicka och hämta ändringar från individers egna repon, är detta inte att föredra eftersom det med lätthet kan skapa förvirring kring vad man själv jobbar med om man inte är försiktig. Vidare vill du att dina medarbetare skall kunna nå repot även om din dator inte är påslagen — ett mer tillförlitligt gemensamt repo är därför ofta användbart. Därför är det föredragna arbetssättet för att samarbeta med någon att sätta upp ett intermediärt repo som ni båda har tillgång till och skicka och hämta ändringar därifrån.

Att köra en Gitserver är ganska rättframt. Först måste du välja vilka protokoll du vill att din server stödjer. Det första avsnittet av detta kapitlet kommer behandla tillgängliga protokoll samt för- och nackdelar av dem. Efterföljande avsnitt kommer beskriva några typiska installationer som använder protokollen och hur då får din server att använda dem. Sist kommer vi att gå igenom lite leverantörslösningar om du inte har något emot att ha din kod på någonannans server och inte vill gå igenom krånglet med att sätta upp och underhålla din egen server.

Om du inte har något intresse av att köra din egen server, kan du hoppa till sista avsnittet av kapitlet för lite valmöjligheter att sätta upp ett tjänstekonto hos några leverantörer och därefter gå vidare till nästa kapitel. Där kommer vi att diskutera olika in- och utgångar av att jobba i en miljö med distribuerad versionshantering.

Ett fjärrepo är generellt ett bart förvar — ett Git repo som inte har något arbetsträd. Eftersom repot bara används för samarbetsknutpunkt finns det ingen anledning att ha en ögonblicksbild utcheckad på disken; det är bara själva Gitdatan. I enklaste termer är ett bart förvar bara innehållet av ditt projekts .git-katalog och inget annat.

Protokollen

Git kan använda fyra olika protokoll för att överföra data: Lokalt, HTTP, SSH samt Git. Här kommer vi gå igenom vad de är och under vilka omständigheter du vill (eller inte vill) använda dem.

Lokala protokollet

Det mest grundläggande är det lokala protokollet, i vilket fjärrförvaret är i en annan katalog på samma dator. Detta används ofta om alla i dit team har tillgång till ett gemensamt filsystem såsom en NFS-montering, eller i det mindre vanliga fallet att alla loggar in på samma dator. Det sistnämnda är inte idealt, eftersom alla dina repoinstanser finns på samma dator, vilket utgör en ökad risk för en katastrofal dataförlust.

Om du har ett delat filsystem kan du klona, skicka till och hämta från ett lokalt filbaserat repo. För att klona ett repo på detta sättet, eller att lägga till en fjärförvar till ett existerande projekt, använder du sökvägen till repot som URL. Till exempel, för att klona ett lokalt repo kan du göra något i stil med:

$ git clone /srv/git/project.git

Eller så kan du göra såhär:

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

Git jobbar något olika om du explicit specificerar file:// i början av URL:en. Om du bara specificerar sökvägen, kommer Git att försöka använda hårda länkar eller att direkt kopiera filerna som behövs. Om du specificerar file://, kommer Git att starta den process som den normalt användef för att överföra data över nätverk, vilken generellt är midre effektiv. Huvudanledningen att specificera prefixet file:// är oim du vill ha en ren kopia av repot med irrelevanta referenser eller objekt som lämnats kvar — normalt efter import från ett annat versionshanteringssystem eller liknande (se Git Internals för underhållsuppgifter). Vi använder vanliga sökvägar här eftersom det nästan alltid går fortare.

För att lägga till ett lokalt repo till ett existerande Gitprojekt, kan du göra något i stil med detta:

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

Då kan du skicka och hämta data från det fjärrförvaret via ditt nya fjärrnamn local_proj, som om du gjorde det över nätverket..

Fördelarna

Fördelarna med filbaserade repon är att de är enkla och använder existerande filrättigheter och nätverksåtkomst. Om du redan har ett delat filsystem till vilket hela teamet har åtkomst är det väldigt enkelt att sätta upp ett repo. Du lägger den bara repokopian någonstans dit alla har delad åtkomst och sätter läs- och skrivrättigheter som du skulle gjort för vilken annan delad mapp som helst. Vi diskuterar hur man exporterar en bar repokopia för detta ändamål i Skaffa Git på en server.

Detta är också ett trevligt alternativ för att snabbt hämta arbete från någon annans arbetsrepo. Om du och en medarbeterare jobbar på samma projekt och de vill att du skall titta på något, är det ofta enklare att köra ett kommando som git pull /home/john/project än att de skall skicka upp sina ändringar till en fjärrserver och att du sedan hämtar dem därifrån.

Nackdelarna

Nackdelarna med denna metod är att delad åtkomst generellt är svårare att konfigurera och nå från flera ställen än ren och skär nätverksåtkomst. Om du vill skicka ändringar från din bärbara dator när du är hemma måste du montera näverksdisken, vilket kan vara svårt och långsamt jämfört med nätverksbaserad åtkomst.

Det är viktigt att nämna att detta nödvändigtvis inte är det snabbaste valet om du använder en delad nätverksdisk av något slag. Ett lokalt repo är bara snabbt om du har snabb åtkomst till datan. Ett repo på en nätverksdisk är ofta långsammare än repo över SSH på samma server, som gör att Git kan köra från lokala diskar på varje system.

Slutligen, detta protokollet skyddar inte repot mot oavsiktlig skada. Varje användare ha full skalåtkomst till “fjärr”-mappen och det finns inget som hindrar dem från att ändra eller ta bort interna Gitfiler och korrumpera repot.

HTTP-protokollen

Git kan kommunicera över HTTP via två olika lägen. Före Git 1.6.6 var det bara ett sätt som var väldigt simpelt och generellt endast med läsåtkomst. I version 1.6.6 introducerades ett nytt smartare protokoll som innebär att Git kan förhandla dataöverföring på ett sätt som liknar hur det gör över SSH. De senaste åren har det nya protokollet blivit väldigt populärt eftersom det är enklare för användaren och smartare i hur den kommunicerar. Den nya versionen refereras ofta till som det Smart HTTP och det äldre sättet som dum HTTP. Vi behandlar det nya smarta HTTP protokollet först.

Smart HTTP

Smart HTTP fungerar väldigt likt SSH- och Gitprotokollen men kör över vanliga HTTPS-portar och kan använda olika HTTP-autentiseringsmekanismer, vilket betyder att det oftast är enklare för användaren än något som SSH eftersom du kan använda autentisera med användarnamn och lösenord snarare än konfigurera SSH-nycklar.

Det har förmodligen blivit det vanligaste sättet att använda Git nu, eftersom det kan konfigureras för att hantera anonyma åtkomst som git:// protokollet, men också att skicka data med autentisering och kryptering som SSH-protokollet. Istället för att konfigurera olika URL:er för dessa saker, kan du använda en enda URL för bägge. Om du försöker skicka och repot kräver autentisering (vilket bör vara normalt förfarande) kan servern fråga efter användarnamn och lösenord. Detsamma gäller för läsåtkomst.

Faktum är att för tjänster som GitHub är URL:en som du använder för att visa repot online (till exempel https://github.com/schacon/simplegit) är samma URL som du kan anväda att klona med och, om du har åtkomst, skicka via.

Dum HTTP

Om server inte svarar med med en Smart HTTP Git tjänst, kommer Gitklienten att försöka falla tillbaka till det enklare dumma HTTP. Det dumma protokollet förväntar sig att det bara Gitrepot kommer att sändas som normala filer från webservern. Det fina i kråksången med Dum HTTP är enkelheten att konfigurera det. I praktiken behöver du du bara lägga ditt Gitrepo under di dokumentroten för din HTTP-server och konfigurera en specifik post-update krok, och du är klar (se Git Hooks). När du gjort det, kan alla med åtkomst till din webserver dit du lade ditt repo också klona det. För att tillåta läsrättigheter för ditt repo över HTTP, gör något i stil med detta:

$ 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. Kroken post-update som normalt kommer med Git kör ett lämpligt kommando (git update-server-info) för att göra hämtning från och kloning av HTTP repon att fungera korrekt. Detta kommando körs när du skickar till detta repo (kanske via SSH), då kan andra folk klona ungefär såhär

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

I detta specifika fallet använder vi sökvägen var/www/htdocs som är vanlig för Apachekonfigurationer, men du kan använda vilken statisk webserver som helst — lägg bara det bara repot på dess plats. Gitdata skickas som vanliga statiska filer (se kapitlet Git Internals för detaljer kring exakt hur det går till).

I gemen väljer du enkom att köra en Smart HTTP server med läs- och skrivrättigheter eller bara tillgängliggöra filerna för läsning via dum HTTP. Det är ovanligt att använda en mix av de två metoderna.

Fördelarna

Vi koncentrerar oss på fördelarna hos den Smarta versionen av HTTP.

Enkelheten med att ha en enda URL för alla typer av åtkomst och att servern själv frågar om autentisering krävs gör saken enklare för slutanvändaren. Att tillåta autentisering med användarnamn och lösenord är en stor fördel jämfört med SSH, eftersom användare inte behöver generera SSH-nycklar lokalt och ladda upp sin publika nycklar till servern innan man kan interagera med den. För modre sofistikerade användare, eller användare på system där SSH är mindre vanligt, är detta en stor fördel i användarvänlighet. Det är också ett väldigt snabbt och effektivt protokoll, i paritet med SSH.

Du kan också tillgängliggöra dina repon med enbart läsåtkomst över HTTPS, vilket betyder att du kan kryptera innehållet innan överföringen eller så kan du gå så långt att kräva signerade SSL-certifikat av klienterna.

En annan trevlik sak är att HTTPS är så mycket mer välanvänt vilket gör att företagens brandväggar ofta är konfigurerade för att tillåta trafik genom dess portar.

Nackdelarna

Git över HTTPS kan vara lite mer trixigt att konfigurera jämfört med SSH på några servrar. Utöver det finns det väldigt få fördelar som andra protokoll har över Smart HTTP när det kommer till att förmedla Gitdata.

Om du använder HTTP för autentisering vid skickande av data är det ibland mer komplicerat att ange dina inloggningsuppgifter än att använda nycklar över SSH. Det finns dock flera verktyg som sparar inloggningsuppgifter, inklusive Keychain på macOS och Credential Manager på Windows, för att göra detta ganska smärtfritt. Läs Credential Storage för att se hur du kan konfigurera säkra sätt att spara inloggningsuggifter för HTTP på ditt system.

SSH-protokollet

Ett vanligt transportprotokoll för Git när man driftar miljön själv är över SSH. Detta eftersom SSH-åtkomst till servrar ofta är konfigurerat på de flesta ställen — och om det inte är det är det lätt att göra. SSH är också ett autentiserat näverksprotokoll och, eftersom det är allmänt förekommande, är lätt att konfigurera och använda.

För att klona ett Gitrepo över SSH så kan du specificera ssh:// i URL:en som såhär:

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

Eller så kan du använda det kortare scp-liknande syntaxen för SSH-protokollet:

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

I båda fall ovan antar Git att du autentiserar dig som den användare du är inloggad som, om du inte specificerar användarnamn.

Fördelarna

Fördelarna att använda SSH är många. Först av allt så är SSH relativt enkelt att konfigurera — SSH-daemoner är vardagsmat, många nätverksadministratörer har erfarenhet av dem, och många OS-distributioner är konfigurerade med dem eller har 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, likt HTTPS, Git och lokala protokollen, är SSH effektivt, vilket gör data så kompakt som möjligt innan överföringen.

Nackdelarna

Den negativa aspekten av SSH är att det inte tillåter anonym åtkomst till ditt Gitrepo. Om du använder SSH, måste folk ha SSH-åtkomst till din maskin, även vid enbart läsrättigheter, vilket gör att SSH inte är smidigt för öppen källkodsprojekt i vilka folk helt enkelt vill klona ditt repo för att undersöka det. Om du bara använder det inom ditt företags nätverk kan SSH vara det enda protokoll du behöver handskas med. Om du vill tillåta anonym läsåtkomst till dina projekt och också vill använda SSH, behöver du konfigurera SSH för dig att skicka data över, men något annat för andra att hämta från.

Gitprotokollet

Slutligen har vi Gitprotokollet. Detta är en speciell daemon som kommer packeterad med Git och som lyssnar på en dedikerad port (9418) som tillhandahåller enb tjänst liknande SSH-protokollet, men utan autentisering. För ett repo för att tillhandahållas över Gitprotokollet, måste du skapa en git-daemon-export-ok-fil — daemonen kommer inte tillgängliggöra repo utan den filen — men å andra sidan finns det ingen säkerhet. Antingen är gitrepot tillgängligt för alla att klona eller så är det inte det. Detta betyder att man generellt inte skickar upp data över detta protokollet. Du kan tillåta skrivaccess men eftersom det inte finns någon autentisering kan vem som helst på internet som har ditt projekts URL skicka data till det. Vi kan konstatera att det är sällsynt.

Fördelarna

Gitprotokollet är ofta det snabbaste tillgängliga nätverksöverföringsprotokollet. Om du hanterar stora mängder trafik för ett publikt projekt eller hanterar väldigt stora projekt som inte kräver autentisering för läsåtkomst är det troligt att du vill konfigurera en Git-daemon för att tillgängliggöra ditt projekt. Det använder samma dataöverföringsmekanism som SSH-protokollet men utan overhead för kryptering och autentisering.d.

Nackdelarna

Nersidan av Gitprotokollet är avsaknaden av autentisering. Det är normalt inte önskvärt för Gitprotokoll att vara den enda åtkomsten för ditt projekt. Man brukar para det med SSH- eller HTTPS-åtkomst för de få utvecklare som har skrivrättigheter och alla andra får använda git:// för enbart läsrättigheter. Det är också förmodligen det svåraste protokollet att konfigurera. Det måste köra sin egen daemon, vilket kräver konfiguration av xinetd, systemd eller liknande vilket inte alltid är en promenad i parken. Det kräver också brandväggskonfiguration av port 9418 vilket inte är en standardport som företags brandväggar alltid tillåter. Bakom stora företags brandväggar är denna obskyra port vanligtvis blockerad.

scroll-to-top