Chapters ▾ 2nd Edition

4.1 Git on the Server - Die Protokolle (The Protocols)

At this point, you should be able to do most of the day-to-day tasks for which you’ll be using Git. However, in order to do any collaboration in Git, you’ll need to have a remote Git repository. Although you can technically push changes to and pull changes from individuals' repositories, doing so is discouraged because you can fairly easily confuse what they’re working on if you’re not careful. Furthermore, you want your collaborators to be able to access the repository even if your computer is offline — having a more reliable common repository is often useful. Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that.

Running a Git server is fairly straightforward. First, you choose which protocols you want your server to support. The first section of this chapter will cover the available protocols and the pros and cons of each. The next sections will explain some typical setups using those protocols and how to get your server running with them. Last, we’ll go over a few hosted options, if you don’t mind hosting your code on someone else’s server and don’t want to go through the hassle of setting up and maintaining your own server.

If you have no interest in running your own server, you can skip to the last section of the chapter to see some options for setting up a hosted account and then move on to the next chapter, where we discuss the various ins and outs of working in a distributed source control environment.

A remote repository is generally a bare repository — a Git repository that has no working directory. Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it’s just the Git data. In the simplest terms, a bare repository is the contents of your project’s .git directory and nothing else.

Die Protokolle (The Protocols)

Git kan vier verskillende protokolle gebruik om data oor te dra: Lokaal, HTTP, Secure Shell (SSH) en Git. Hier bespreek ons wat dit is en in watter basiese omstandighede jy dit wil (of nie wil nie) gebruik.

Die Lokale Protokol (Local Protocol)

Die mees basiese is die lokale protokol, waarin die afgeleë bewaarplek (remote repository) in 'n ander gids (directory) op dieselfde gasheer (host) is. Dit word dikwels gebruik as almal op jou span toegang het tot 'n gedeelde lêerstelsel (shared filesystem) soos 'n NFS-aankoppeling (mount), of in die minder waarskynlike geval dat almal op dieselfde rekenaar aanmeld (logs in). Laasgenoemde sou nie ideaal wees nie, omdat al jou kodedatabasis-bewaarplek-instansies op dieselfde rekenaar sou bly, wat 'n katastrofiese verlies veel waarskynliker maak.

As jy 'n gedeelde aangekoppelde lêerstelsel het, kan jy van 'n plaaslike lêergebaseerde bewaarplek kloon (clone), daarheen push, en daarvandaan pull. Om so 'n bewaarplek te kloon, of om een as 'n remote by 'n bestaande projek te voeg, gebruik die pad na die bewaarplek as die URL. Om 'n plaaslike bewaarplek te kloon, kan jy byvoorbeeld iets soos dit uitvoer:

$ git clone /srv/git/project.git

Of jy kan dit doen:

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

Git werk 'n bietjie anders as jy eksplisiet file:// aan die begin van die URL spesifiseer. As jy net die pad spesifiseer, probeer Git harde skakels (hardlinks) gebruik of die lêers wat dit benodig direk kopieer. As jy file:// spesifiseer, vuur Git die prosesse aan wat dit normaalweg gebruik om data oor 'n netwerk te dra, wat oor die algemeen veel minder doeltreffend is. Die hoofrede om die file:// voorvoegsel te spesifiseer is as jy 'n skoon kopie van die bewaarplek wil hê met oortollige verwysings of objekte uitgelaat — gewoonlik na 'n invoer (import) vanaf 'n ander VCS of iets soortgelyks (sien Git Internals vir onderhoudstake). Ons sal die normale pad hier gebruik omdat dit amper altyd vinniger is.

Om 'n plaaslike bewaarplek by 'n bestaande Git-projek te voeg, kan jy iets soos dit uitvoer:

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

Dan kan jy na en van daardie remote push en pull via jou nuwe remote-naam local_proj asof jy dit oor 'n netwerk gedoen het.

Die Voordele (The Pros)

Die voordele van lêergebaseerde bewaarplekke is dat hulle eenvoudig is en bestaande lêerregte (file permissions) en netwerktoegang gebruik. As jy reeds 'n gedeelde lêerstelsel het waartoe jou hele span toegang het, is dit baie maklik om 'n bewaarplek op te stel. Jy sit die kale bewaarplekkopie (bare repository copy) iewers waar almal gedeelde toegang toe het en stel die lees-/skryfregte in soos jy vir enige ander gedeelde gids sou doen. Ons sal bespreek hoe om 'n kale bewaarplekkopie vir hierdie doel uit te voer (export) in Git op 'n Bediener kry (Getting Git on a Server).

Dit is ook 'n lekker opsie om vinnig werk van iemand anders se werkende bewaarplek te gryp. As jy en 'n medewerker aan dieselfde projek werk en hulle wil hê jy moet iets uitsit (check out), is dit dikwels makliker om 'n opdrag soos git pull /home/john/project uit te voer as dat hulle na 'n afgeleë bediener push en jy dit daarna daarvandaan afhaal (fetch).

Die Nadele (The Cons)

Die nadele van hierdie metode is dat gedeelde toegang oor die algemeen moeiliker is om op te stel en vanaf verskeie liggings te bereik as basiese netwerktoegang. As jy van jou skootrekenaar wil push wanneer jy by die huis is, moet jy die afgeleë skyf aanheg (mount), wat moeilik en stadig kan wees in vergelyking met netwerkgebaseerde toegang.

Dit is belangrik om te vermeld dat dit nie noodwendig die vinnigste opsie is as jy een of ander gedeelde aankoppeling (shared mount) gebruik nie. 'n Plaaslike bewaarplek is slegs vinnig as jy vinnige toegang tot die data het. 'n Bewaarplek op NFS is dikwels stadiger as die bewaarplek oor SSH op dieselfde bediener, wat Git in staat stel om vanaf plaaslike skywe op elke stelsel te loop.

Ten slotte beskerm hierdie protokol nie die bewaarplek teen perke skade nie. Elke gebruiker het volle doptoegang (shell access) tot die “remote” gids, en niks verhoed hulle om interne Git-lêers te verander of te verwyder en die bewaarplek te korrumpeer nie.

Die HTTP-protokolle (The HTTP Protocols)

Git kan oor HTTP kommunikeer met twee verskillende modusse. Voor Git 1.6.6 was daar net een manier waarop dit dit kon doen, wat baie eenvoudig en oor die algemeen leesalleen (read-only) was. In weergawe 1.6.6 is 'n nuwe, slimmar protokol bekendgestel wat behels dat Git data-oordrag intelligent kan onderhandel op 'n manier soortgelyk aan hoe dit oor SSH doen. In die laaste paar jaar het hierdie nuwe HTTP-protokolle baie gewild geword aangesien dit eenvoudiger vir die gebruiker is en slim is oor hoe dit kommunikeer. Na die nuwe weergawe word dikwels verwys as die Slim HTTP-protokol (Smart HTTP) en die ouer manier as Dom HTTP (Dumb HTTP). Ons sal eers die nuwere Smart HTTP-protokol dek.

Smart HTTP

Smart HTTP werk baie soortgelyk aan die SSH- of Git-protokolle, maar loop oor standaard HTTPS-poorte en kan verskeie HTTP-verifikasiemeganismes gebruik, wat beteken dat dit dikwels makliker vir die gebruiker is as iets soos SSH, aangesien jy dinge soos gebruikersnaam-/wagwoordverifikasie kan gebruik in plaas daarvan om SSH-sleutels op te stel.

Dit het waarskynlik nou die gewildste manier geword om Git te gebruik, aangesien dit opgestel kan word om beide anoniem te bedien soos die git:// protokol, en kan ook oor gepush word met verifikasie en enkripsie soos die SSH-protokol. In plaas daarvan om verskillende URL’e vir hierdie dinge te moet opstel, kan jy nou 'n enkele URL vir beide gebruik. As jy probeer push en die bewaarplek verifikasie vereis (wat dit normaalweg behoort te doen), kan die bediener vir 'n gebruikersnaam en wagwoord vra. Dieselfde geld vir leestoegang.

Trouens, vir dienste soos GitHub is die URL wat jy gebruik om die bewaarplek aanlyn te bekyk (byvoorbeeld https://github.com/schacon/simplegit) dieselfde URL wat jy kan gebruik om te kloon en, as jy toegang het, oor te push.

Dumb HTTP

As die bediener nie met 'n Git HTTP-slimdiens reageer nie, sal die Git-kliënt probeer terugval op die eenvoudiger Dom HTTP-protokol (Dumb HTTP). Die Dom-protokol verwag dat die kale Git-bewaarplek bedien word soos normale lêers vanaf die webbediener. Die skoonheid van Dumb HTTP is die eenvoud van die opstel daarvan. Basies is al wat jy hoef te doen om 'n kale Git-bewaarplek onder jou HTTP-dokumentwortel (document root) te plaas en 'n spesifieke post-update haak (hook) op te stel, en jy is klaar (sien Git-hake (Git Hooks)). Op daardie oomblik kan enigiemand wat toegang het tot die webbediener waarvoor jy die bewaarplek geplaas het, ook jou bewaarplek kloon. Om leestoegang tot jou bewaarplek oor HTTP toe te staan, doen iets soos dit:

$ 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

Dis al. Die post-update haak wat by verstek saam met Git kom, laat die toepaslike opdrag (git update-server-info) loop om HTTP-afhaling en -kloning behoorlik te laat werk. Hierdie opdrag word uitgevoer wanneer jy na hierdie bewaarplek push (oor SSH miskien); dan kan ander mense kloon via iets soos:

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

In hierdie spesifieke geval gebruik ons die /var/www/htdocs pad wat algemeen is vir Apache-opstellings, maar jy kan enige statiese webbediener gebruik — sit net die kale bewaarplek in sy pad. Die Git-data word as basiese statiese lêers bedien (sien die Git Internals hoofstuk vir besonderhede oor presies hoe dit bedien word).

Oor die algemeen sou jy óf kies om 'n lees-/skryf Smart HTTP-bediener te laat loop óf eenvoudig die lêers as leesalleen op die Dumb-manier toeganklik hê. Dit is seldsaam om 'n kombinasie van die twee dienste te laat loop.

Die Voordele (The Pros)

Ons sal konsentreer op die voordele van die Smart-weergawe van die HTTP-protokol.

Die eenvoud om 'n enkele URL vir alle tipes toegang te hê en dat die bediener slegs vra wanneer verifikasie nodig is, maak dinge baie maklik vir die eindgebruiker. Om met 'n gebruikersnaam en wagwoord te kan verifieer, is ook 'n groot voordeel bo SSH, aangesien gebruikers nie SSH-sleutels lokaal hoef te genereer en hul publieke sleutel na die bediener op te laai voordat hulle daarmee kan wisselwerking hê nie. Vir minder gesofistikeerde gebruikers, of gebruikers op stelsels waar SSH minder algemeen is, is dit 'n groot voordeel in bruikbaarheid. Dit is ook 'n baie vinnige en doeltreffende protokol, soortgelyk aan dié van SSH.

Jy kan ook jou bewaarplekke leesalleen oor HTTPS bedien, wat beteken jy kan die inhoudsoordrag enkripteer; of jy kan so ver gaan as om die kliënte spesifieke getekende SSL-sertifikate te laat gebruik.

Nog 'n oulike ding is dat HTTP en HTTPS so algemeen gebruikte protokolle is dat korporatiewe brandmure dikwels opgestel is om verkeer deur hul poorte toe te laat.

Die Nadele (The Cons)

Git oor HTTPS kan 'n bietjie moeiliker wees om op te stel in vergelyking met SSH op sommige bedieners. Behalwe dit is daar baie min voordeel wat ander protokolle bo Smart HTTP het vir die bediening van Git-inhoud.

As jy HTTP vir geverifieerde push gebruik, is die verskaffing van jou aanmeldbewyse (credentials) soms meer ingewikkeld as om sleutels oor SSH te gebruik. Daar is egter verskeie aanmeldbewys-kasinstrumente (credential caching tools) wat jy kan gebruik, insluitend Keychain-toegang op macOS en Credential Manager op Windows, om dit taamlik pynloos te maak. Lees Die Stoor van Aanmeldbewyse (Credential Storage) om te sien hoe om veilige HTTP-wagwoordkassing op jou stelsel op te stel.

Die SSH-protokol (The SSH Protocol)

'n Algemene vervoerprotokol vir Git wanneer self-gehuisves word, is oor SSH. Dit is omdat SSH-toegang tot bedieners reeds op die meeste plekke opgestel is — en indien nie, is dit maklik om te doen. SSH is ook 'n geverifieerde netwerkprotokol en, omdat dit alomteenwoordig is, is dit oor die algemeen maklik om op te stel en te gebruik.

Om 'n Git-bewaarplek oor SSH te kloon, kan jy 'n ssh:// URL soos dit spesifiseer:

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

Of jy kan die korter scp-agtige sintaksis vir die SSH-protokol gebruik:

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

In beide bogenoemde gevalle, as jy nie die opsionele gebruikersnaam spesifiseer nie, aanvaar Git die gebruiker as wie jy tans aangemeld is.

Die Voordele (The Pros)

Die voordele van die gebruik van SSH is baie. Eerstens is SSH relatief maklik om op te stel — SSH-daemons kom algemeen voor, baie netwerkadministrateurs het ervaring daarmee, en baie bedryfstelselverspreidings (OS distributions) is daarmee opgestel of het gereedskap om dit te bestuur. Tweedens is toegang oor SSH veiling — alle data-oordrag is geënkripteer en geverifieer. Laastens, soos die HTTPS-, Git- en Lokale protokolle, is SSH doeltreffend, wat die data so kompak moontlik maak voordat dit oorgedra word.

Die Nadele (The Cons)

Die negatiewe aspek van SSH is dat dit nie anonieme toegang tot jou Git-bewaarplek ondersteun nie. As jy SSH gebruik, moet mense SSH-toegang tot jou masjien hê, selfs in 'n leesalleen-kapasiteit, wat nie SSH bevorderlik maak vir oopbronprojekte waarvoor mense eenvoudig jou bewaarplek dalk wil kloon om dit te ondersoek nie. As jy dit slegs binne jou korporatiewe netwerk gebruik, is SSH dalk die enigste protokol waarmee jy te kampe het. As jy anonieme leesalleen-toegang tot jou projekte wil toelaat en ook SSH wil gebruik, sal jy SSH vir jou moet opstel om oor te push, maar iets anders vir ander om van af te haal.

Die Git-protokol (The Git Protocol)

Ten slotte het ons die Git-protokol. Dit is 'n spesiale daemon wat saam met Git verpak word; dit luister op 'n toegewyde poort (9418) wat 'n diens soortgelyk aan die SSH-protokol lewer, maar met absoluut geen verifikasie of kriptografie nie. Sodat 'n bewaarplek oor die Git-protokol bedien kan word, moet jy 'n git-daemon-export-ok lêer skep — die daemon sal nie 'n bewaarplek bedien sonder daardie lêer daarin nie — maar behalwe dit is daar geen sekuriteit nie. Óf die Git-bewaarplek is beskikbaar vir almal om te kloon, óf dit is nie. Dit beteken dat daar oor die algemeen geen push oor hierdie protokol is nie. Jy kan push-toegang aktiveer, maar gegewe die gebrek aan verifikasie, kan enigiemand op die internet wat jou projek se URL vind, na daardie projek push. Dit is genoeg om te sê dat dit seldsaam is.

Die Voordele (The Pros)

Die Git-protokol is dikwels die vinnigste netwerkoordragprotokol wat beskikbaar is. As jy baie verkeer vir 'n openbare projek bedien of 'n baie groot projek bedien wat nie gebruikersverifikasie vir leestoegang vereis nie, sal jy waarskynlik 'n Git-daemon wil opstel om jou projek te bedien. Dit gebruik dieselfde data-oordragmeganisme as die SSH-protokol, maar sonder die enkripsie- en verifikasie-bokoste (overhead).

Die Nadele (The Cons)

As gevolg van die gebrek aan TLS of ander kriptografie, kan kloning oor git:// lei tot 'n arbitrêre kode-uitvoeringskwesbaarheid (arbitrary code execution vulnerability), en moet dit dus vermy word tensy jy weet wat jy doen.

  • As jy git clone git://example.com/project.git uitvoer, kan 'n aanvaller wat bv. jou roeteerder (router) beheer, die bewaarplek wat jy net gekloon het, modifiseer en kwaadwillige kode daarin plaas. As jy dan die kode wat jy pas gekloon het kompileer/laat loop, sal jy die kwaadwillige kode uitvoer. Om git clone http://example.com/project.git uit te voer, moet om dieselfde rede vermy word.

  • Om git clone https://example.com/project.git uit te voer, ly nie aan dieselfde probleem nie (tensy die aanvaller 'n TLS-sertifikaat vir example.com kan verskaf). Om git clone git@example.com:project.git uit te voer, ly slegs aan hierdie probleem as jy 'n verkeerde SSH-sleutel-vingerafdruk aanvaar.

Dit het ook geen verifikasie nie, d.w.s. enigiemand kan die bewaarplek kloon (al is dit dikwels presies wat jy wil hê). Dit is ook waarskynlik die moeilikste protokol om op te stel. Dit moet sy eie daemon laat loop, wat xinetd- of systemd-konfigurasie of iets dergelijks vereis, wat nie altyd 'n uitstappie in die park is nie. Dit vereis ook brandmuurtoegang tot poort 9418, wat nie 'n standaardpoort is wat korporatiewe brandmure altyd toelaat nie. Agter groot korporatiewe brandmure word hierdie obskure poort algemeen geblokkeer.