-
1. Úvod
- 1.1 Správa verzí
- 1.2 Stručná historie systému Git
- 1.3 Základy systému Git
- 1.4 Příkazový řádek
- 1.5 Instalace systému Git
- 1.6 První nastavení systému Git
- 1.7 Získání nápovědy
- 1.8 Shrnutí
-
2. Základy práce se systémem Git
-
3. Větve v systému Git
- 3.1 Větve v kostce
- 3.2 Základy větvení a slučování
- 3.3 Správa větví
- 3.4 Postupy při práci s větvemi
- 3.5 Vzdálené větve
- 3.6 Přeskládání
- 3.7 Shrnutí
-
4. Git na serveru
- 4.1 Protokoly
- 4.2 Zprovoznění Gitu na serveru
- 4.3 Generování veřejného klíče SSH
- 4.4 Nastavení serveru
- 4.5 Démon Git
- 4.6 Chytrý HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti hostování u třetí strany
- 4.10 Shrnutí
-
5. Distribuovaný Git
- 5.1 Distribuované pracovní postupy
- 5.2 Přispívání do projektu
- 5.3 Správa projektu
- 5.4 Shrnutí
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Ladění v systému Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Shrnutí
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Atributy Git
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Shrnutí
-
9. Git a ostatní systémy
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Shrnutí
-
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Balíčkové soubory
- 10.5 The Refspec
- 10.6 Přenosové protokoly
- 10.7 Správa a obnova dat
- 10.8 Environment Variables
- 10.9 Shrnutí
-
A1. Appendix A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Shrnutí
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
4.8 Git na serveru - GitLab
GitLab
Jenže GitWeb je příliš zjednodušený. Pokud hledáte modernější, plnohodnotný server pro Git, můžete si místo GitWebu nainstalovat jedno z několika jiných open-source řešení. GitLab patří k těm populárnějším. Použijeme jej jako příklad a probereme si jeho instalaci a používání. Je trochu složitější než GitWeb a bude pravděpodobně vyžadovat víc úsilí při správě, ale představuje mnohem plnohodnotnější alternativu.
Instalace
GitLab je webová aplikace pracující nad databází, takže instalace vyžaduje trochu víc úsilí než ostatní servery pro Git. Naštěstí je jeho instalace velmi dobře dokumentována a podporována.
Nainstalování GitLabu lze dosáhnout několika metodami. Pokud chcete získat rychle něco, co funguje, můžete si stáhnout obraz pro virtuální počítač, nebo instalátor na jedno kliknutí z https://bitnami.com/stack/gitlab. Potom upravíte konfiguraci tak, aby vyhovovala vašemu konkrétnímu prostředí. Bitnami doplnilo do přihlašovací obrazovky (zpřístupněné stiskem alt-→) jednu pěknou vychytávku. Ukáže vám pro nainstalovaný GitLab jeho IP adresu a přednastavené uživatelské jméno a heslo.
![Přihlašovací obrazovka Bitnami pro virtuální počítač s GitLab.](png/bitnami.png)
Při ostatních činnostech postupujte podle návodu v souboru readme ke GitLab Community Edition. Najdete ho na https://gitlab.com/gitlab-org/gitlab-ce/tree/master. Naleznete zde rady pro instalaci GitLabu s využitím Chef recipes, virtuální počítač na Digital Ocean a balíčky RPM a DEB (které byly v době psaní tohoto textu ve stádiu beta). Najdete zde in „neoficiální“ rady pro zprovoznění GitLabu na nestandardních operačních systémech a databázích, plně manuální popis instalace a řadu dalších témat.
Správa
Rozhraní pro správu GitLabu je přístupné přes web.
Prohlížeč jednoduše nasměrujte na hostitelské jméno nebo IP adresu, kde je GitLab nainstalovaný a přihlaste se jako uživatel admin.
Přednastavené uživatelské jméno je admin@local.host
a heslo je 5iveL!fe
. (Jakmile ho zadáte, budete vyzváni k tomu, abyste ho změnili.)
Po přihlášení klikněte v menu vpravo nahoře na ikonu „Admin area“.
Uživatelé
Za uživatele se v GitLabu považují účty, které odpovídají lidem.
Uživatelské účty nejsou nijak složité. Jde v podstatě o souhrn osobních informací, které jsou přivěšeny k přihlašovacím údajům.
Každý uživatelský účet má svůj jmenný prostor, který představuje logické seskupení projektů patřících uživateli.
Pokud by uživatelka jane
měla projekt pojmenovaný project
, pak by url tohoto projektu bylo http://server/jane/project.
![Obrazovka GitLabu pro správu uživatelů.](png/gitlab-users.png)
Odstranění uživatele lze provést dvěma způsoby. „Zablokováním“ (Block) uživateli zabráníte přihlásit se ke GitLabu, ale všechna data pod tímto uživatelským jménem budou zachována a revize podepsané jeho uživatelským e-mailem budou stále odkazovat do jeho profilu.
„Zničením“ uživatele (Destroy) naopak dosáhnete jeho úplného odstranění z databáze a ze systému souborů. Všechny projekty a data z jeho jmenného prostoru jsou odstraněny — včetně skupin, které uživatel vlastní. Zjevně jde o trvalejší a destruktivnější změnu a používá se zřídka.
Skupiny
Gitlabovská skupina je sbírkou projektů, která je doplněna o informace o tom, jak k nim mohou přistupovat uživatelé.
Každá skupina má svůj jmenný prostor (stejně, jak je tomu u uživatelů), takže pokud se ve skupině training
nachází projekt materials
, bude mu odpovídat url http://server/training/materials.
![Obrazovka pro správu gitlabovských skupin.](png/gitlab-groups.png)
Každá skupina je svázána s množinou uživatelů a každý uživatel má přiděleny úrovně oprávnění k projektům skupiny a ke skupině samotné. Úrovně oprávnění se pohybují v rozmezí od „Guest“ (host; pouze debatní témata a přístup do diskuse) až po „Owner“ (vlastník; plná oprávnění ke skupině, k správě jejích členů a jejích projektů). Typů oprávnění je příliš mnoho na to, abychom je zde uváděli, ale na administrátorské stránce GitLabu najdete užitečný odkaz.
Projekty
Gitlabovský projekt zhruba odpovídá jednomu gitovému repozitáři. Každý projekt spadá pod jediný jmenný prostor — buď pod uživatele nebo pod skupinu. Pokud projekt patří uživateli, pak má vlastník projektu přímou kontrolu nad tím, kdo může k projektu přistupovat. Pokud projekt patří skupině, uplatní se také oprávnění definovaná na úrovni skupiny.
U každého projektu je také určena úroveň viditelnosti, kterou se dá ovlivnit, kdo má ke stránkám projektu a k repozitáři přístup pro čtení.
Pokud je projekt označený jako Private (soukromý), pak musí vlastník projektu přímo přidělovat přístupová oprávnění konkrétním uživatelům.
Projekt označený Internal (interní) je viditelný pro kteréhokoliv přihlášeného uživatele, a projekt označený Public (veřejný) je viditelný pro všechny.
Poznamenejme, že tyto úrovně řídí jak přístup pro git fetch
, tak přístup k webovému uživatelskému rozhraní projektu
Zásuvné moduly
GitLab podporuje použití zásuvných modulů jak na straně projektu, tak na úrovni systému. Pro každý s těchto typů provádí gitlabovský server při výskytu události odpovídající HTTP POST s popisem ve formátu JSON. Nabízí se tím parádní způsob propojení vašich gitových repozitářů a GitLabu se zbytkem automatizované podpory vývoje, jako jsou CI servery[14], diskusní místnosti, nebo nástroje pro zveřejňování.
Základní použití
První věc, kterou budete chtít v GitLabu udělat, je vytvoření nového projektu. Provedete to kliknutím na ikonu „+“ na nástrojové liště. GitLab se vás zeptá na jméno projektu, pod jaký jmenný prostor by měl spadat a jakou by měl mít přidělenu úroveň viditelnosti. Většina věcí, kterou zde zadáte, nemá trvalou platnost a později je můžete upravit přes rozhraní pro nastavení. Kliknete na „Create Project“ a je to.
Jakmile je projek založen, budete ho asi chtít spojit s lokálním gitovým repozitářem.
Každý projekt je dostupný přes HTTPS nebo SSH — pro konfiguraci vzdáleného gitového repozitáře lze použít libovolný z těchto protokolů.
Odpovídající URL odkazy se zobrazují v horní části domácí stránky projektu.
Následující příkaz vytvoří pro existující lokální repozitář vzdálený odkaz pojmenovaný gitlab
:
$ git remote add gitlab https://server/namespace/project.git
Pokud lokální kopie repozitáře neexistuje, můžeme provést následující:
$ git clone https://server/namespace/project.git
Webové uživatelské rozhraní zpřístupňuje několik užitečných pohledů na samotný repozitář. Každá stránka projektu zobrazuje nedávnou aktivitu a odkazy v horní části vedou k pohledům na soubory a na poznámky k revizím (commit log).
Spolupráce
Nejsnadněji lze spolupráce na gitlabovském projektu dosáhnout přímým přidělením oprávnění pro odesílání do repozitáře (push) jinému uživateli. Uživatele můžete do projektu přidat tak, že v nastavení projektu přejdete do sekce „Members“ (členové) a novému uživateli přidělíte úroveň přístupu. (O různých úrovních přístupu se trochu zmiňujeme v části Skupiny.) Když uživateli přidělíte úroveň přístupu „Developer“ (vývojář) nebo vyšší, může uživatel do repozitáře přímo (beztrestně) odesílat revize a větve.
Další, trochu víc oddělený způsob spolupráce, je založen na použití žádostí o sloučení (merge request).
Tento rys umožňuje řízeným způsobem přispívat do projektu každému uživateli, který jej vidí.
Uživatel s přímým přístupem může jednoduše vytvořit větev, odeslat do ní revize a otevřít požadavek na začlenění jeho větve zpět do master
, nebo do jakékoliv jiné větve.
Uživatelé, kteří nemají oprávnění pro odesílání do repozitáře, mohou vytvořit odštěpený projekt (fork, čili jejich vlastní kopii), odeslat revize do své kopie a otevřít požadavek na začlenění z jejich odštěpeného projektu zpět do hlavního projektu.
Tento model umožňuje vlastníkovi plnou kontrolu nad tím, co se dostává do repozitáře a kdy, přičemž přispívat mohou i nedůvěryhodní (neprověření) uživatelé.
Hlavními prvky diskusí s dlouhou životností jsou v GitLabu požadavky na začlenění a tématické diskuse (issues). Každý požadavek na začlenění umožňuje diskutovat o navrhované změně jak pro každý řádek zvlášť (čímž se podporuje jakýsi odlehčený způsob recenzování kódu), tak i obecné diskusní vlákno o změně jako celku. Obojí lze přidělit konkrétním uživatelům nebo organizovat po milnících.
V této části jsme se zaměřili především na rysy GitLabu související s Gitem. Ale jde o vyspělý projekt, který nabízí řadu dalších rysů, které pomáhají při spolupráci v týmu, jako jsou wiki projektu a nástroje pro údržbu systému. Jednou z výhod GitLabu je, že jakmile gitlabovský sever zprovozníte, budete jen zřídka muset upravovat konfigurační soubor nebo přistupovat k serveru přes SSH. Většina úkonů správy a obecné používání se dá provádět přes rozhraní webového prohlížeče.