Správa linuxového serveru: Git na vlastním serveru

Systémy pro správu verzí jako Git nacházejí široká uplatnění, nejenom v rámci programování. V tomto článku se dozvíte něco málo o Gitu, zejména jak vytvořit centrální úložiště pro Git repozitář na vlastním serveru.

Úvod

Systém pro správu verzí (známý pod zkratkami SCM nebo VCS) je software, který spravuje změny ve vašich (zejména textových) datech. Můžete tak snadno zjistit, ve kterých souborech se co změnilo, kdy se to změnilo a kdo to změnil. Pomocí SCM se organizují práce vývojářů na softwarových projektech. Ale SCM poslouží na jakákoliv textová data, nejen na zdrojový kód. V unixových systémech to často bývají konfigurační soubory, které mají v těchto systémech textový charakter. Mohou to ale také být třeba zdrojové kódy rozsáhlejšího dokumentu tvořeného v LaTeXu či za pomoci konverzních nástrojů typu Asciidoc, Pandoc, txt2tags apod.

Git byl vyvinut pro potřeby vývoje linuxového jádra (kde nahradil komerční a nesvobodný Bitkeeper) a postupem času se stal jedním z nejpopulárnějších SCM nástrojů, alespoň ve světě svobodného softwaru.

Existuje řada služeb, které vám umožní vytvořit si svoje vlastní Git repozitáře, hostované na serveru příslušného poskytovatele. GitHub je zde nejznámějším, ale nikoliv jediným příkladem. Tyto služby však mohou být za určitých okolností zpoplatněné (např. když nechcete svůj repozitář vystavit světu) a samozřejmě podléhají určitým podmínkám, které se vám mohou, ale také nemusí líbit. Máte-li vlastní server, můžete si centrální úložiště pro Git repozitář(e) vytvořit na něm.

Pokud máte ještě v živé paměti články o zprovoznění Redmine na linuxovém serveru, dodám, že Redmine podporuje řadu SCM nástrojů a podpora Gitu samozřejmě nechybí.

Distribuovaný SCM a centrální úložiště

Git je distribuovaný SCM, což znamená, že nepotřebuje centrální bod, se kterým by musel udržovat spojení, aby byl schopen realizovat základní úkony (tím se liší od centralizovaných SCM jako CVS či SVN). Všechny základní operace prováděné Gitem jsou realizovány lokálně, v rámci vašeho souborového systému (konkrétně pak v podadresáři .git). Proto jsou také pekelně rychlé. Centrální server tedy v zásadě není nutný, ale má-li na projektu pracovat více lidí, nebo chcete-li online zálohu či centrální bod, abyste mohli snadno synchronizovat své změny napříč několika počítači, centrální server se vám může hodit.

Je třeba zmínit, že Git není jediným pod Linuxem dostupným distribuovaným SCM. Můžete použít např. Mercurial nebo Bazaar.

Základy práce s Gitem

Na Git jako takový se zde podrobněji zaměřovat nebudu, ale jakousi základní kuchařku vám přesto poskytnu.

Je-li to poprvé, co vůbec používáte Git, bylo by dobré se mu představit (ideálně ještě před prováděním commitů):

git config --global user.name 'Jméno Příjmení'
git config --global user.email mail@example.cz

Vytvoření Git repozitáře představuje jeden jediný příkaz, a to v adresáři, který chcete Gitem spravovat (samozřejmě včetně podadresářů):

git init

Tento příkaz vytvoří výše zmíněný .git podadresář s příslušnými výchozími konfiguračními soubory. Poté je třeba přidat příslušné soubory:

git add .

Výše uvedený příkaz přidá celý aktuální adresář včetně podadresářů. Můžete samozřejmě specifikovat konkrétní soubor nebo soubory:

git add soubor1.txt soubor2.txt

Následně můžete vytvořit první commit, tedy uložit aktuální stav sledovaných souborů do repozitáře:

git commit -m 'Popis commitu'

V tuto chvíli by měl být aktuální stav všech sledovaných souborů uložen. Jakmile provedete změny, můžete je uložit, tedy „commitnout“ buď automaticky (commitnou se všechny změněné soubory):

git commit -a -m 'Popis commitu'

Nebo můžete selektivně „commitnout“ jen něco:

git add soubor.txt
git commit -m 'Popis změny souboru soubor.txt'

Aktuální změny oproti poslednímu commitu je možné zjistit pomocí:

git status

Podrobnější přehled o změnách můžete zjistit pomocí:

git diff --stat

A konkrétní diff pak obdržíte pomocí:

git diff

Samotný git add ukládá daný soubor do tzv. staging area, tudíž pokud mezi tím příslušný soubor změníte a pak provedete commit, tak uložíte změny, které byly aktuální v době zadání git add. Soubory uložené ve „staging area“ můžete vyjmout pomocí git reset HEAD.

Existují také grafické nadstavby Gitu, které vám usnadní získání informací o změnách, popřípadě samotnou správu repozitáře, například gitk (měl by být součástí distribuce Gitu).

Chcete-li se o používání Gitu dozvědět více, podívejte se do závěru článku, kde je řada odkazů na zdroje o Gitu, a to i v češtině. Nechybí ani jedna velice užitečná kniha přeložená do češtiny.

Git přes SSH

V tomto dílu vám představím to nejjednodušší řešení centralizovaného Git repozitáře, které existuje. Na serveru vám k tomu stačí pouze běžící SSH server. Toto řešení je vhodné pro soukromé repozitáře, které nechcete nikde vystavovat a kde nepotřebujete přístup více osob. Na komplikovanější řešení se zaměřím v dalších dílech.

Nacházíte-li se v adresáři s Git repozitářem, jako první krok exportujte repozitář do správného „formátu“ a překopírujte jej na server. Předpokladem je, že v domovském adresáři vzdáleného uživatele uzivatel existuje adresář git.

git clone --bare .git /tmp/muj_repositar.git
scp -r /tmp/muj_repositar.git uzivatel@server.example.cz:/home/uzivatel/git/muj_repositar.git

Nyní je repozitář na serveru vytvořen. Stačí tedy Gitu říci, že tento vzdálený repozitář existuje:

git remote add origin ssh://uzivatel@server.example.cz/home/uzivatel/git/muj_repositar.git

V tuto chvíli máte možnost commitnuté změny poslat na server, popřípadě si změny z centrálního repozitáře stáhnout, a samozřejmě máte možnost vzdálený repozitář naklonovat třeba na nový počítač. Samotné publikování změn na server provedete takto:

git push

Máte-li na serveru dostupné změny, které nemáte k dispozici v lokálním repozitáři, můžete si je stáhnout a začlenit:

git pull

No a konečně, pokud se ocitnete na novém počítači, kde daný repozitář není k dispozici, můžete jeho aktuální stav naklonovat pomocí git clone, tímto způsobem:

git clone ssh://root@lucifer.krkavec.net/root/git/muj_repositar.git

Toto řešení je velmi jednoduché, ale v zásadě pokrývá pouze ty nejprostší potřeby. Máte-li více lidí a potřebujete-li definovat k repozitáři třeba read-only přístup, potřebujete mírně sofistikovanější řešení, kterým se budu zabývat v příštím dílu seriálu.