Autor Zpráva
midlan
Profil
Ahoj,
začal jsem používat git ale moc nevím jak vyřešit situaci kdy používám například nějaký framework, který má samostatný vzdálený repozitář. Nyní ho mám v .gitignore, ale správně by měl být asi spolu s aplikací trackovaný. Znamená to tedy, že když vyjde update frameworku, já si repozitář stáhnu a udělám commit například s popiskem "framework updated". Jak říkám jsem začátečník, ale chtěl bych to hned od začátku řešit správně. Děkuji za rady.
Jan Tvrdík
Profil
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
Profil
Jan Tvrdík:
Koukal jsem na ten composer, ale moc se mi nelíbí.

Jan Tvrdík:
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.

Takže pokud vyjde nějaká nová verze framworku, udělám pull v jeho repozitáři a v repozitáři aplikace commit? Jak popisuji v prvním příspěvku.
Jan Tvrdík
Profil
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.
midlan
Profil
Jan Tvrdík:
Smím se zeptat proč? Umožňuje rychlejší a pohodlnější aktualizaci knihoven než ostatní uvedené varianty.
Je to zas něco navíc co bych tolik nevyužil, zatím jsem rád, že jakž takž umím ovládat git. Používáme dvě knihovny a jednu z nich píšeme sami, takže občas stáhnout novou verzi jedné knihovny pro nás není problém. Pokud bych měl v projektu několik knihoven, určitě bych ho využil.
llook
Profil
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:

git submodule add https://github.com/nette/nette.git libs/Nette

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
Profil
llook:
To nevypadá špatně, jen nachápu proč při klonu musím inicializovat a aktualizovat submoduly. Jak to pak vypadá, když vyjde aktializace třeba zmíněného Nette?

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?
Jan Tvrdík
Profil
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).
llook
Profil
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:

cd libs/Nette
git pull
cd ../..
git commit -a -m 'Updated Nette'

Takto stáhneš novou verzi a aktualizuješ hash submodulu.
midlan
Profil
Jan Tvrdík:
Tím chci říct, že otázka je podle mě špatně položená.
Ne byly položeny otázky dvě, jedna se týkala submodulů a druhá byla k tomu ručnímu řešení. 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.

llook:
Uvedený příklad je na submoduly? Pokud ano můžu v submodulu přispívat, jako v klasickém repozitáři? Jak vlastně můžu přispět do veřejného repozitáře jako například Nette?
llook
Profil
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.
Jan Tvrdík
Profil
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
Profil
llook:
Adresář submodulu je normální repozitář, takže v jeho adresáři můžeš dělat cokoli, třeba i commitovat.
to si nějak neumím představit spolu s tím co jsi napsal výše:
verzuje se jenom odkaz na repo plus hash commitu.
pak se tedy budou verzovat odkaz + soubory co jsem změnil?

Jan Tvrdík:
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.
Jan Tvrdík
Profil
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?
midlan
Profil
Jan Tvrdík:
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.
My ale jednu z těch knihoven píšeme sami takže pro ní tam repozitář bude snad ne?

Vaše odpověď


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: