Chapters ▾ 2nd Edition

4.2 Git on the Server - Git op 'n Bediener kry (Getting Git on a Server)

Git op 'n Bediener kry (Getting Git on a Server)

Ons gaan nou die opstel van 'n Git-diens (Git service) op jou eie bediener (server) behandel wat hierdie protokolle gebruik.

Note

Ons sal hier die opdragte en stappe wys om 'n eenvoudige, vereenvoudigde installasie op 'n Linux-gebaseerde bediener op te stel, alhoewel dit ook moontlik is om hierdie dienste op 'n macOS of Windows bediener te laat loop. Die werklike opstel van 'n produksie-bediener binne jou infrastruktuur sal byna sekerlik verskil in die manier waarop die sekuriteitsmaatreëls (security measures) ingerig is of die spesifieke bedryfstelsel-hulpmiddels (operating system tools) wat gebruik word, maar hopelik sal dit jou 'n idee gee van wat alles behels word.

Om aanvanklik 'n Git-bediener op te stel, moet jy 'n bestaande bewaarplek (repository) na 'n nuwe kale bewaarplek (bare repository) uitvoer — 'n bewaarplek wat geen werkgids (working directory) bevat nie. Dit is oor die algemeen maklik om te doen. Om jou bewaarplek te kloon (clone) om sodoende 'n nuwe kale bewaarplek te skep, voer jy die clone opdrag met die --bare opsie uit. Die konvensie is om gidse (directories) wat kale bewaarplekke bevat, met .git te laat eindig, soos hier:

$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.

Jy behoort nou 'n kopie van die Git-gids data in jou my_project.git gids te hê.

Dit is min of meer gelykstaande aan:

$ cp -Rf my_project/.git my_project.git

Daar is 'n paar klein verskille in die konfigurasielêer (configuration file), maar dit kom op dieselfde neer. Dit neem die Git-bewaarplek self, sonder 'n werkgids (working directory), en skep 'n gids spesifiek net daarvoor.

Die kale bewaarplek op 'n bediener plaas (Putting the Bare Repository on a Server)

Noudat jy 'n kale kopie (bare copy) van jou bewaarplek het, is al wat jy hoef te doen om dit op 'n bediener te plaas en jou protokolle op te stel. Kom ons neem aan jy het 'n bediener opgestel genaamd git.example.com, waarop jy SSH-toegang het, en waar jy al jou Git-bewaarplekke onder die /srv/git gids wil stoor. Aannemende dat /srv/git op daardie bediener bestaan, kan jy hierdie nuwe bewaarplek beskikbaar stel deur jou kale bewaarplek daarnatoe te kopieer:

$ scp -r my_project.git user@git.example.com:/srv/git

Vanaf daardie oomblik kan ander gebruikers wat SSH-toegang tot dieselfde bediener het en leestoegang (read access) tot die /srv/git gids het, jou bewaarplek kloon (clone) deur dit uit te voer:

$ git clone user@git.example.com:/srv/git/my_project.git

As 'n gebruiker met SSH op 'n bediener aanteken (logs in) en skryftoegang (write access) het tot die /srv/git/my_project.git gids, dan het hulle outomaties ook push-toegang.

Git sal outomaties die korrekte groep-skryfregte (group write permissions) aan 'n bewaarplek toeken as jy die git init opdrag met die --shared opsie uitvoer. Let daarop dat die uitvoering van hierdie opdrag geen vasleggings (commits), verwysings (refs), ens. sal uitvee nie.

$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared

Jy sien hoe eenvoudig dit is om 'n Git-bewaarplek te neem, 'n kale weergawe (bare version) te skep, en dit op 'n bediener te plaas waartoe jy en jou medewerkers SSH-toegang het. Nou is julle gereed om aan dieselfde projek saam te werk.

Dit is belangrik om daarop te let dat dit letterlik al is wat jy hoef te doen om 'n bruikbare Git-bediener te laat loop waartoe verskeie mense toegang het: skep bloot 'n paar rekeninge (accounts) met SSH-toegang op 'n bediener, en plaas 'n kale bewaarplek êrens waar al daardie gebruikers lees- en skryftoegang het. Jy is gereed — jy het niks anders nodig nie.

In die volgende afdelings sal jy sien hoe jy meer komplekse opstellings kan maak. Hierdie bespreking sal dek hoe om nie gebruikersrekeninge vir elke gebruiker te hoef skep nie, asook publieke leestoegang tot bewaarplekke, grafiese webkoppelvlakke (web interfaces), en meer. Maar hou in gedagte dat om op 'n privaat projek met mense saam te werk, al wat jy nodig het, 'n SSH-bediener en 'n kale bewaarplek is.

Klein Opstellings (Small Setups)

As jy deel is van 'n klein groepie of net met Git in jou organisasie begin en slegs 'n paar ontwikkelaars het, kan dinge vir jou eenvoudig wees. Een van die mees ingewikkelde aspekte van die opstel van 'n Git-bediener is die bestuur van gebruikers. As jy sommige bewaarplekke as leesalleen (read-only) vir sekere gebruikers wil hê, en lees/skryf (read/write) vir ander, kan toegang en regte (permissions) 'n bietjie moeiliker wees om te reël.

SSH-toegang (SSH Access)

As jy reeds 'n bediener het waartoe al jou ontwikkelaars SSH-toegang het, is dit oor die algemeen die maklikste om jou eerste bewaarplek (repository) daar op te stel, aangesien jy byna niks hoef te doen nie (soos in die vorige afdeling beskryf). As jy meer komplekse toegangsbeheer (access control) op jou bewaarplekke wil hê, kan jy dit opstel met die normale lêerstelsel-regte (file system permissions) van die bedryfstelsel (operating system) wat op jou bediener loop.

As jy jou bewaarplekke op 'n bediener wil plaas wat nie rekeninge (accounts) het vir almal in jou span aan wie jy skryftoegang (write access) wil gee nie, sal jy SSH-toegang vir hulle moet opstel. Ons aanvaar dat jy 'n bediener het waarmee jy dit kan doen, dat jy reeds 'n SSH-bediener geïnstalleer het, en dat dit die manier is waarop jy toegang tot die bediener verkry.

Daar is 'n paar maniere waarop jy aan almal in jou span toegang kan gee. Die eerste is om vir almal rekeninge (accounts) te skep, wat eenvoudig is maar redelik tydrowend kan wees. Jy wil waarskynlik nie adduser uitvoer en tydelike wagwoorde vir elke gebruiker instel nie.

Die tweede metode is om 'n enkele 'git'-gebruiker op die masjien te skep, elke gebruiker wat skryftoegang moet kry te vra om vir jou 'n publieke SSH-sleutel (SSH public key) te stuur, en daardie sleutel by die ~/.ssh/authorized_keys lêer van daardie nuwe gebruiker by te voeg. Van daardie oomblik af sal almal toegang tot die masjien hê via die 'git'-gebruiker. Dit beïnvloed die vasleggingsdata (commit data) op geen manier nie — die SSH-gebruiker waarmee jy aanteken, sal nie die vasleggings wat jy gemaak het, beïnvloed nie.

'n Ander manier om dit te doen, is om jou SSH-bediener te laat verifieer (authenticate) deur middel van 'n LDAP-bediener of 'n ander gesentraliseerde verifikasiebron wat miskien reeds vir jou opgestel is. Solank elke gebruiker doptoegang (shell access) op die masjien kan kry, behoort enige SSH-verifikasiemeganisme waaraan jy kan dink, te werk.