Můj začátek s verzovacím systémem git

S verzovacím systémem git jsem začínal pracovat velmi rychle, aniž bych měl čas naučit se jej do hloubky. Vše jsem se učil během práce na skutečném projektu, což mě brzy dovedlo k nutnosti použití pokročilých postupů. Doufám, že popis mých začátků bude užitečný i někomu jinému.

1. Subversion, nebo git?

Na začátku musím napsat, že jsem naprosto spokojen se subversion. V současnosti již model větvení není takovou noční můrou, jakou býval. Hlavní výhodou, kterou git přináší, již tedy není větvení. Tou je možnost práce s verzemi (commit) v době, kdy není dostupné internetové připojení. Právě proto jsem se rozhodl, že použiju git pro svůj projekt.

2. Můj první projekt

Mým prvním projektem, na který jsem použil git, je kniha psaná hindsky v typografickém systému XeLaTeX. Na knize jsem začal pracovat již dříve a historii jsem měl v subversion. Nyní jsem potřeboval pokračovat v práci i na notebooku na místech bez internetového připojení. Pro tuto chvíli jsem se vzdal zachování existující historie v subversion a založil jsem si na svém stolním počítači nový repositář:

cd
mkdir MyBook
cd MyBook
git init

Do tohoto repositáře jsem zkopíroval zdrojové soubory z pracovní kopie subversion a provedl jsem:

git add *
git commit -m 'Files copied from the subversion working copy.'

3. Snadné sdílení

Původně jsem si myslel, že adresář MyBook prostě přenesu na notebook, tam budu pracovat, a po návratu přenesu zpět na stolní počítač. To však není správná cesta, jak používat verzovací systém, protože nikdy nevíte, na kterém počítači je aktuální stav. V komentáři článku, který popisuje metody hostování repozitářů, jsem našel poznámku, že je možno využít Dropbox. To mi připadalo jako metoda sice ne vhodná pro trvalou práci, ale elegantní pro rychlý začátek. Založil jsem si tedy repozitář na Dropboxu, přidal jej jako vzdálený zdroj a publikoval v něm aktuální stav:

cd ~/Dropbox
mkdir MyBook
cd MyBook
git init --bare
cd ~/MyBook
git remote add origin ~/Dropbox/MyBook/
git push origin master

V této chvíli jsem ještě neznal přepínač --set-upstream.

Proč není cloud obecně pro repozitáře vhodný? Právě proto, že můžete provést git push i bez internetové konektivity. Pak může na cloudu vzniknout konfliktní kopie, která vede k vážným problémům, a to zejména v případě, kdy si její existence nevšimnete.

4. Můj první repozitář

Pro svůj první repositář jsem se rozhodl použít WebDAV, protože jej používám již pro subversion. Postupoval jsem podle tohoto návodu: Aquì estamos! Git repository with Apache (via WebDAV) and gitweb. V návodu není zdaleka napsáno vše důležité, zejména s ohledem na to, že můj projekt není veřejný a přístup musí být šifrován a chráněn heslem. Protože však o serveru Apache vím téměř vše, byla to snadná úloha.

Nyní bych mohl přesunout repositář z Dropboxu do správného adresáře serveru a opravit přístupová práva. Plánoval jsem však, že nově vytvořený systém použiju i pro další projekty. Pak je výhodnější, když repozitář vytváří přímo server, což zajistí automaticky přidělení správných přístupových práv. Takový PHP skript již mám pro subversion. Jeho úprava pro git byla záležitost na několik minut.

Projekt jsem přenesl do nového repozitáře a vazbu s Dropboxem jsem zrušil.

git remote add web https://my.server.at.home/git/MyBook/
git push web master
git remote remove origin
git remote rename web origin

5. Nekvalifikovaný certifikát

Protokol https vyžaduje certifikát. Pro testovací účely jsem si instaloval Apache na svém domácím počítači a zřídil vlastní testovací certifikační autoritu. Tato autorita je všem programům neznámá. Mohu nakonfigurovat git tak, aby validitu certifikátů nekontroloval, ale to dělat nechci. A protože chci na svém serveru hostovat několik projektů, chci ověřování svých certifikátů nakonfigurovat globálně. Google mi poradil jednoduchou instrukci:

git config --global http.sslcainfo /path/to/MyCAcertificate.pem

Zmíněný příkaz jsem provedl ještě před instalací prvního repositáře postupem popsaným v minulé kapitole. Vše fungovalo dobře až do chvíle, než jsem zkusil kontaktovat server s kvalifikovaným certifikátem. Problém spočívá v tom, že v této konfiguraci git ověřuje certifikáty všech serverů proti mé certifikační autoritě. Konfigurační parametr bych tedy musel zadávat lokálně pro každý klon, což se mi ale nechce. Je však možno přiřadit certifikát ke konkrétnímu serveru. Problém jsem tedy vyřešil těmito příkazy:

git config --global --unset http.sslcainfo
git config --global http."https://my.server.at.home/".sslcainfo /path/to/MyCAcertificate.pem

Co mi chybí je funkcionalita webových prohlížečů a klienta subversion. Certifikát je nejprve ověřen pomocí zabudovaných certifikačních autorit a pouze v případě neúspěchu je vyzkoušen uživatelem instalovaný certifikát. Bohužel git v dokumentaci neobsahuje srozumitelnou informaci, zda je to možné, a pokud ano, jak se to nakonfiguruje.

6. Obnova historie

Můj projekt byl nyní rozdělen na dvě části. Začátek histrie byl v subversion, pokračování obsahuje git. Byl jsem z toho poněkud nešťastný a začal jsem přemýšlet, zda by se s tím dalo něco dělat. Nejprve jsem chtěl starý repositář subversion překonvertovat pro git. Jako nejlepší doporučení mi připadal program svn2git. Instalace programu je snadná, a protože jsem byl jediným uživatelem repozitáře, soubor authors se dá snadno vytvořit ručně.

Konverze ze subversion vyžaduje nový, prázdný repozitář, proto jsem jej vytvořil. V tomto případě byla konverze rychlá, protože projekt je velmi malý a jeho historie krátká. Vše bylo provedeno těmito příkazy:

cd
mkdir BookFromSVN
cd BookFromSVN
git init
svn2git https://my.server.at.home/svn/MyBook -v

Mým záměrem bylo stáhnout ohsah, který obsahuje git, a zkusit to nějak sjednotit. Líbila se mi však URL mého repozitáře, proto jsem nejprve přímo na serveru přejmenoval adresář MyBook na OLD-MyBook a pomocí PHP skriptu jsem založil nový repozitář MyBook. Nakonec jsem vytvořil novou větev a natáhl do ní aktuální obsah:

cd ~/BookFromSVN
git checkout -b fromgit
git remote add oldgit https://my.server.at.home/git/OLD-MyBook/
git pull oldgit master

Možná jsem raději měl použít rebase, ale použil jsem merge. Vidím tedy větev začínající nikde, je to místo, kde git navazuje na historii subversion. Použitím git diff mohu prověřit, že první revize z repozitáře git je identická s poslední revizí ze subversion. Mohl jsem tedy odstranit větev a poslat obsah do nově vytvořeného repozitáře se starým názvem. Zde jsou použité příkazy:

git checkout master
git merge fromgit
git branch -d fromgit
git remote add origin https://my.server.at.home/git/MyBook/
git push --set-upstream origin master
git remote remove oldgit

Nyní jsem mohl pokračovat v práci v tomto novém klonu. Zajímavé pro mě bylo, že po chvíli práce, kdy jsem pomocí git push úpravy zveřejnil, jsem se přesto mohl vrátit ke starému lokálnímu klonu a příkaz git pull bez problému natáhl sjednocenou historii.

7. Co jsem se naučil

V tomto projektu jsem se nenaučil větvení, protože zde nemá význam. Později určitě použiju tag. Vyzkoušel jsem si však práci se vzdálenými repozitáři (remote). A nabyl jsem dojmu, že i zde se dá použít jeden z mých oblíbených citátů:

It [Babbage's analytical engine] has no pretentions whatever to originate anything but it can do whatever we know how to order it to perform. (Ada Countess of Lovelace)

8. Závěr

Silné stránky verzovacího systému git jsou paradoxně i jeho stránkami slabými. V subversion stačí jeden příkaz k odeslání modifikovaných souborů do centrálního repozitáře, git vyžaduje tři příkazy. Pro nováčka může být náročné si na to zvyknout a nedělat chyby. Je nutné číst git status často a pozorně. V subversion může několik vývojářů úspěšně přispívat do trunku s minimálním rizikem konfliktu. Obávám se, že to v systému git neplatí, zvláště pokud vývojáři pracují bez internetového připojení a používají git push až po delším časovém období. Domnívám se, že feature branch je nutností pro přežití při týmové práci.

Vzhledem k výše uvedenému budu ještě dlouho používat subversion, i když svn2git již umím používat. Na druhou stranu vidím v blízké budoucnosti projekty (i jednouživatelské), kde git pro mě bude velmi důležitým nástrojem.

Jsem donucen k tomu, abych svou programátorskou prací sponzoroval hudebníky a jiné autorské svazy. Ukládám totiž své programy, vstupní data i výsledky výpočtů na CD a DVD.