git repozitáře v repozitáři

midlan:
„Jak říkám jsem začátečník, ale chtěl bych to hned od začátku řešit správně.“
V současnosti nabývá na popularitě Composer – nástroj pro správu PHP závislostí. Mají poměrně dobře zpracovanou dokumentaci, takže podrobnosti hledej tam. Na případné nejasnosti se samozřejmě klidně ptej tady.

Pokud se rozhodneš nepoužít Composer (což je v současnosti asi preferované řešení), tak existují ještě dvě významné alternativy. Začněme tou horší – Git submoduly. Ty řeší přesně to, že součástí jednoho Git repozitáře je jiný Git repozitář. Nicméně práce s nimi je nepohodlná a většina lidí, co je vyzkoušela je časem i opustila.

Nejjednodušší, ale poměrně bezproblémové a pravděpodobně i nejrozšířenější řešení, je zdrojové kódy dané knihovny (v tomto případě frameworku) normálně nakopírovat do repositáře (bez té .git složky). Tedy součástí repositáře s tvým projektem nebude historii použitých knihoven.

(Poznámka: Varianta nemít framework ani informace o potřebné verzi součástí repozitáře je asi vůbec ta nejhorší možná.)

midlan:
„Koukal jsem na ten composer, ale moc se mi nelíbí.“
Smím se zeptat proč? Umožňuje rychlejší a pohodlnější aktualizaci knihoven než ostatní uvedené varianty.

„udělám pull v jeho repozitáři a v repozitáři aplikace commit“
V podstatě ano.

Git samotný má přesně na tohle submoduly: http://git-scm.com/book/en/Git-Tools-Submodules

Pokud chceš třeba do složky libs/Nette vložit repozitář Nette, tak použiješ příkaz:


Tím se ti tam ten repozitář naklonuje, ale když se podíváš na git status, tak ve tvém projektu git eviduje jenom dva změněné soubory: .gitmodules a libs/Nette. Když je commitneš (git commit -a), tak se ti zaverzuje informace odkud se submodul má naklonovat a v jaké má být revizi.

Když potom tento svůj repozitář budeš klonovat, tak musíš v tom klonu provést git submodule init a git submodule update, aby se ti všechny submoduly naklonovaly a checkoutly do požadované revize.

Funguje to celkem dobře, ale je to takový hloupý mechanizmus - verzuje se jenom odkaz na repo plus hash commitu. Proto se teď víc prosazují balíčkovací systémy jako Composer pro PHP nebo Bower pro JS/CSS, tyhle systémy nabízí víc možností.

midlan:
„Pokud bych použil to ruční řešení co jsem popisoval výše, když poté udělám git commit, bude git commitovat do hlavního repozitáře nebo subrepozitáře?“
Použijeme-li definici, že subrepozitář je každý repozitář, který je obsažen v jiném repozitáři jako submodul, tak budeš commitovat repozitář i subrepozitář zároveň neboť oba termíny budou odkazovat na to samé. Tím chci říct, že otázka je podle mě špatně položená.

Pořád platí, že existují v zásadě tři možnosti popsané výše. Varianta (2) – submoduly se liší od varianty (3) – ručně zkopírovat tím, že v případě (2) commituješ do repozitáře pouze odkaz na repozitář a hash commitu (viz vysvětlení od llooka), zatímco v případě (3) commituješ do repozitáře všechny soubory dané knihovny (ale bez historie dané knihovny).

Když vyjde aktualizace Nette, tak ty máš ve svém repozitáři pořád odkaz na starou verzi, takže git submodule update stáhne tu starou verzi. Když bys ji ve svém projektu chtěl aktualizovat, tak:


Takto stáhneš novou verzi a aktualizuješ hash submodulu.

Adresář submodulu je normální repozitář, takže v jeho adresáři můžeš dělat cokoli, třeba i commitovat. Pokud jde ale o push do vzdáleného repozitáře, tak k tomu musíš mít oprávnění, což u Nette nemáš.

Pokud chceš přispět do projektu, ke kterému nemáš oprávnění, tak u projektů na Githubu se to dělá tak, že si uděláš fork projektu, v tom forku uděláš změny a pak do původního projektu pošleš pull request na začlenění těch změn. Správce toho původního repozitáře pak může ty změny začlenit.

midlan:
„Pořád tedy nevím jestli bude git při "ručním řešení" dělat při commitu v subrepozitáři, commit subrepozitáře nebo toho hlavního.“
Při ručním řešení neexistuje nic, co bychom označovali jako subrepositář.

midlan:
„pak se tedy budou verzovat odkaz + soubory co jsem změnil?“
Ano i ne =) V repositáři tvého projektu bude verzovaný jen odkaz na repu a hash commit (tak jak ti to už po několikáté vysvětlil llook). Změněné soubory budou verzovány v repositáři té dané knihovny (což je úplně jiný repositář).

> „Při ručním řešení neexistuje nic, co bychom označovali jako subrepositář.“
> Dobře, tak repozitář zanořený v jiném repozitáři.
Není tam ani žádný repositář uvnitř jiného repositáře. Je tam složka. V té složce jsou soubory. Tyto soubory tvoří tu knihovnu.

Očividně máš dost problém si to to představit, neboť od příspěvku [#2] tady furt popisujeme to samý. Co takhle si to zkusit?