Git hooky a alternativy ke Githubu

Správa linuxového serveru: Git hooky a alternativy ke Githubu

V tomto dílu bude problematika Gitu uzavřena. Budou představeny Git hooky, tedy možnost skriptování navázaného na události v Git repozitáři a alternativy ke Githubu, které můžete nasadit na svůj server.

Git hooky

Git obsahuje jednu velmi podstatnou vlastnost, která se dá velmi dobře využít na serveru. Pokud jste třeba někdy zabrousili do vod frameworku Ruby on Rails, určitě jste slyšeli o hostingu Heroku, kde se nasazení (deployment) aplikací řeší právě přes Git. Je jistě velmi pohodlné provést aktualizaci webové aplikace na serveru prostřednictvím obyčejného git push. Takovou funkcionalitu je možné realizovat právě pomocí Git „háčků“.

Git hook je obyčejný shellový skript, který je umístěn v podadresáři hooks v adresáři obsahujícím Git repozitář (obvykle .git/hooks). Git tyto hooky spouští v reakci na jisté události, resp. v konkrétním okamžiku (před či po nějaké operaci). To, zda bude skript spuštěn, nebo ne, je dáno jeho oprávněním (je-li spustitelný, bude spuštěn). Ke tvorbě skriptu můžete využít jakéhokoliv skriptovacího jazyka, nebo zůstat u Bashe (popř. jiného oblíbeného shellového interpretu).

Seznam jednotlivých hooků i s jejich případnými parametry a činností, na kterou je příslušný hook, naleznete v tabulce níže:

Název skriptu

Vázáno na

Parametry

applypatch-msg

běh git-am skriptu

název souboru s popisem commitu

pre-applypatch

běh git-am, po aplikování patche a commitu

-

pre-commit

běh git-commit před commitem

-

prepare-commit-msg

běh git-commit ihned po připravení výchozího popisu commitu

1-3 parametry: jméno souboru s popisem commitu, zdroj zprávy (viz dokumentace), SHA1 commitu

commit-msg

běh git-commit

název souboru s popisem commitu

post-commit

běh git-commit po provedení commitu

-

pre-rebase

běh git-rebase před prováděním rebase

-

post-checkout

běh git-checkout po aktualizaci pracovního stromu

3 parametry: ref předchozí HEAD, ref následující HEAD, druh checkoutu (viz dokumentace)

post-merge

běh git-merge po úspěšném provedení merge

typ merge (viz dokumentace)

pre-receive

běh git-receive-pack na serveru před prováděním aktualizace

žádné, ale přijímá vstup na STDIN (viz dokumentace)

update

běh git-receive-pack na serveru po aktualizaci dat, ale před aktualizací referencí

název reference, starý SHA1, nový SHA1

post-receive

běh git-receive-pack na serveru po aktualizaci referencí

žádné, ale přijímá vstup na STDIN (viz dokumentace)

post-update

běh git-receive-pack na serveru po aktualizaci referencí

proměnlivý počet, seznam aktualizovaných referencí

pre-auto-gc

běh git-gc --auto, před provedením operace

-

Přehledovou tabulku doporučuji doplnit dokumentací. Stejně tak doporučuji si projít příklady skriptů, které by měly být součástí libovolného Git repozitáře. Naleznete tam nejenom příklady použití, ale také užitečné komentáře o použití daných háčků.

Stejně jako existují místní a vzdálené Git repozitáře, můžete specifikovat různé místní a vzdálené háčky. Můžete tedy používat jednu sadu funkcionality lokálně a jinou vzdáleně.

Jak je z přehledové tabulky asi patrné, jednotlivé háčky je možné použít pro ledacos. K výše zmíněné aktualizaci webové aplikace po provedení „push“ operace z místního repozitáře může posloužit háček post-update. K samotnému rozbalení obsahu repozitáře můžete použít třeba tento postup:

git archive --format=tar HEAD | (cd /var/www/prezentace && tar xf -)

Na Git háčky je ale možné „pověsit“ i samotnou správu repozitářů, různé kontroly a pojistky. Ukončení skriptu jiným chybovým stavem než nulou (např. exit 1) má v některých případech za následek selhání dané operace. Můžete tak odmítat push na základě specifických kritérií.

Alternativy ke Githubu

Github je nepochybně velmi zdařilý projektový hosting. Není však jediným hostingem podporujícím Git. Ten podporuje i řada jiných, jako např. Sourceforge, Google code apod. To vše jsou však webové služby. Nejsou open source a není možné je nasadit na vlastní server. Máte možnost buď akceptovat jejich podmínky, nebo se poohlédnout po nějaké alternativě. K těmto projektům existuje několik alternativ.

Girocco

Girocco je Git hosting, který lze označit jako GitWeb na steroidech. Girocco je na Gitwebu založeno a ovládá se stejně. Obsahuje samozřejmě potřebné vlastnosti pro Git hosting, jako registraci uživatelů/projektů apod., a některé vlastnosti navíc. Autorem je Petr Baudiš a software je provozován na známém repozitáři repo.or.cz. Pro svou funkci potřebuje webový server, Git a GitWeb. Lze ho propojit s Git démonem. Podporuje zrcadlení repozitářů (můžete jej tedy používat jako záložní úložiště pro některé své repozitáře hostované jinde) a forkování projektů.

Gitorious

Gitorious je založený na Ruby on Rails a šířený pod licencí GNU Affero GPL verze 3. Ta se liší od klasické GNU/GPL tím, že zdrojový kód je třeba zpřístupnit nejen příjemcům při distribuci softwaru, ale také při jeho zpřístupnění uživatelům přes síť. Gitorious je Web 2.0 aplikace ve stylu Githubu, je mu tedy o něco blíže než Girocco. Oproti GitWebu obsahuje navíc vestavěnou wiki, kterou je možné použít pro dokumentaci projektu.

Žádný z těchto projektů neobsahuje všechny funkce Githubu, jako např. komentování, bug tracker apod. Pokud takové funkce potřebujete, je možné zkombinovat některé z těchto řešení s jiným open-source projektem – kupříkladu, open-source bug trackerů existuje celá řada (Flyspray, Bugzilla, Mantis apod.). Jediné, co budete muset oželet, je integrace těchto nástrojů s Git hostingem.

Redmine, Trac a ostatní

Kromě Git hostingů existují také systémy pro správu (softwarových) projektů, které mohou mít rovněž podporu Gitu. Ta může zahrnovat jak prohlížení repozitářů, tak třeba integraci s bug trackerem. Vytvoření repozitáře a přístup (se zápisem) je obvykle nutné řešit jinak, nicméně tyto nástroje mohou obsahovat řadu užitečných komponent jako integrované wiki, bug trackery apod. Mezi tyto nástroje patří v tomto seriálu již zmiňovaný Redmine nebo např. Trac.

Závěr

Tím bych tento díl, stejně jako téma Git uzavřel. Na závěr nemohu nezmínit, že existuje řada jiných SCM nástrojů, kterým jsem se zde nevěnoval (např. Mercurial, Bazaar, SVN apod.). Řada z nich je open source a je možné (v případě centralizovaných SCM i nutné) je nasadit na server. Jsou opatřeny různými vlastnostmi a rozhodně bych doporučoval se na ně podívat.