Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Lukáš 18. 08. 2015, 14:56:00
-
Jsem začínající uživatel GITu a narazil jsem na jeden problém. Potřeboval bych checkoutnout jen podadresář - ne celý repozitář.
Jde o to, že mám repozitář s projektem a ten obsahuje krom zdrojáků i podklady, dokumentaci atp.
Na server ale potřebuji nahrát jen zdrojáky a zbytek (např. podklady) nepotřebuji - dokonce na ně na serveru nemám ani dost místa.
Po hledání jsem zjistil, že na toto existuje od verze 1.7 funkce sparse-checkout (http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/), ale ta se mi nějak nepodařila rozjet:
echo some/dir/ >> .git/info/sparse-checkout
mi vypisuje, že adresář neexistuje.
Také jsem našel zmínku, že:
git clone --no-checkout
by měl pomoci, ale to se mi taky nepodařilo.
Jak se takovýto problém obyčejně řeší? Pokud je nejlepší ten sparse-checkout, tak k čemu slouží ten příkaz
git remote add –f <name> <url>
co je uveden v článku?
-
A ten repozitar je inicializovany?
git init Pretoze ten ukazkovy priklad z tej stranky funguje naramne.
-
To jo, ale tento příkaz jsem nedělal, protože mu nerozumím. Nevím k čemu je a co tam mám dosadit:
git remote add –f <name> <url>
Ty příkazy z článku se mají dělat na místě kde chci tu část repozitáře nebo tam kde mám repozitář, ze kterého budu tahat?
-
Checkout v GITu se dělá z lokálního repozitáře. Tuším, že s trochou snahy jde nadefinovat, ve kterém adresáři se ten repozitář nachází, ale pořád je při běžném použití na tom stroji, ze kterého se checkoutuje. Ale pořád na rozdíl od SVN na tom stroji bude celý repozitář, ne jen checkout. Při klonování repozitáře je možné omezit historii (--depth), ale pokud vím, tak nejde jen vybrat některé adresáře/soubory.
Pomocí sparse-checkout by mělo jít vytáhnout z lokálního repozitáře jen ten adresář, který chcete. Ale pořád na tom serveru bude kompletní repozitář, kde ty podklady, dokumentace atd. budou (a tedy to bude zřejmě velké). Pokud tam může být repozitář, jen nechcete v checkoutu věci, které nepotřebujete, je zřejmě sparse-checkout to, co hledáte.
git remote add sdělí lokálnímu repozitář, že existuje nějaký jiný, se kterým si může povídat (vyměňovat data)
Pokud se na server ta dokumentace nevejde, nemůže tam být ani repozitář s ní. Pak pravděpodobně chcete pomocí git archive vytáhnout část repozitáře, která patří na server a zkopírovat ji tam bez pomoci gitu.
-
Jestli jsem to pochopil správně tak chcete omezit to co je uloženo v repositáři (hlavně na serveru). Ale sparse/checkout se týka pouze pracovniho adresare, neboli toho co je na lokálním pc. Repositar je tedy vždy kompletni ale v pracovnim adresari se pracuje jenom se zvolenou částí.
V gitu označuje commit vždy stav vsech souboru v daném čase plus odkaz na předchozí commit/y (pomocí SHA1 hash), nejde publikovat jenom část stromu, protože by se změnil hash všech commitů a tak by se jednalo o jiné repository.
Já to řeším rozdělením do dvou repository (kde to vnitřní může být submodul nebo prostě jen vnořené repository). Vnější git pak uchovává pouze aktuální commit vnořeného repo. ale už ne vlastní data, to už se ve vnořeném repository spravuje samostatně.
Pokud už máte spoustu commitů kde to je spojeno tak může být problém to rozdělit, mělo by jít pustit na všech předchozích kommitech skript (pomocí filter-branch) který smaže adresář s dokumentací a nebo opačně, vše ostatní.
To ale nevratně změní SHA1 jednotlivých commitů takže se to bude tvářit jako nové repository které nebude kompatibilní s předchozími.
-
Ano, tedy sparse-checkout pro mě nebude. Z důvodu bezpečnosti a úspory místa nechci na webserver nahrávat nic co tam není potřeba. Takže celý repozitář vč. podkladů mám na strojích, kde se na projektu pracuje, ale na server chci dávat pouze část.
Dokonce ani nutně nepotřebuji (přestože by to bylo lepší - viz níže) aby byla data na serveru nějak verzována, protože nepředpokládám, že by někdo něco chtěl měnit přímo na serveru a změny někam commitovat. Takže by mi stačilo něco jako má SVN svn export (pokud si dobře vzpomínám), kdy dojde k vytvoření kopie požadovaného adresáře bez .svn dat.
Jen kdyby to šlo přímo na serveru kde chci data nahrávat.
U SVN jsem to dělal tak, že jsem na serveru checkoutnul požadovaný podadresář (tam to lze) a pak už jen v případě potřeby použil svn update a měl jsem na serveru aktuální verzi. Výhodou bylo, že jsem mohl nahrát i starší revizi atp.
GIT tedy něco takového neumožňuje? Mohu nahrát pouze celý repozitář nebo soubory nahrávat přes FTP ručně?
-
A co to resit poradne? Takze job na CI serveru, ktery dela deploy a da se parametrizovat verzi repa (defaultne head)?
-
Já to řeším rozdělením do dvou repository (kde to vnitřní může být submodul nebo prostě jen vnořené repository). Vnější git pak uchovává pouze aktuální commit vnořeného repo. ale už ne vlastní data, to už se ve vnořeném repository spravuje samostatně.
Toto mi zní jako řešení mého problému. Můžete mě prosím nasměrovat na nějaké info o vnořenách repozitářích nebo mi ještě poradit jak na to?
Stačí klasicky vytvořit repozitář, tam nahrát podklady atp. a v tomto repozitáři vytvořit adresář určený pro webserver a v něm vytvořit další repozitář, který pak budu klonova na webserveru?
-
A co to resit poradne? Takze job na CI serveru, ktery dela deploy a da se parametrizovat verzi repa (defaultne head)?
Obávám se, že na to zatím nemám dostatek zkušeností. Popravdě Vašemu postu vůbec nerozumím :(
-
Myslim, ze byla primarne hloupost to resit jako jedine repository, takze bych se primarne zameril na zmenu timto smerem.
-
Obávám se, že na to zatím nemám dostatek zkušeností. Popravdě Vašemu postu vůbec nerozumím :(
CI = Continous Integration
http://www.martinfowler.com/articles/continuousIntegration.html
-
A co to resit poradne? Takze job na CI serveru, ktery dela deploy a da se parametrizovat verzi repa (defaultne head)?
+1 Výstupem sestavení produktu by měl být balíček (.deb, .rpm, .war, .ear, .tar.gz atd.), který se pak nasazuje (na testy, do produkce). Zdrojáky tam nejsou potřeba resp. nepatří tam.
-
Ano, tedy sparse-checkout pro mě nebude. Z důvodu bezpečnosti a úspory místa nechci na webserver nahrávat nic co tam není potřeba. Takže celý repozitář vč. podkladů mám na strojích, kde se na projektu pracuje, ale na server chci dávat pouze část.
Dokonce ani nutně nepotřebuji (přestože by to bylo lepší - viz níže) aby byla data na serveru nějak verzována, protože nepředpokládám, že by někdo něco chtěl měnit přímo na serveru a změny někam commitovat. Takže by mi stačilo něco jako má SVN svn export (pokud si dobře vzpomínám), kdy dojde k vytvoření kopie požadovaného adresáře bez .svn dat.
Jen kdyby to šlo přímo na serveru kde chci data nahrávat.
Když pominu to že deployment aplikace by se skutečně měl dělat jinak (jak to radí ostatní), tak
to co hledáš je git archive
git archive --format tar --remote ssh://server.org/path/to/git HEAD docs/usage | tar zxf -
-
+1 Výstupem sestavení produktu by měl být balíček (.deb, .rpm, .war, .ear, .tar.gz atd.), který se pak nasazuje (na testy, do produkce). Zdrojáky tam nejsou potřeba resp. nepatří tam.
Z toho co píšete mi přijde, že GIT je určen pouze pro kompilované jazyky :D
Co třeba PHP? V takovém případě zdrojáky na server patří a export do .tar.gz mi moc užitečný nepřijde.
Jestli mám špatný už koncept používání verzovacího systému, rád se poučím, ale v tomto případě zatím nechápu co mi chcete říct.
Programuji ve více jazycích a už dlouho používám verzovací systém. Používal jsem SVN a teď se snažím přecházet na GIT. Vždy mám v projektu jak zdrojáky, tak podklady. Každý kdo na projektu pracuje potřebuje i podklady. Navíc ty se leckdy také verzují (návrhy DB, soubory s poznámkami atp.)
Vše funguje jak bych chtěl a jak jsem zvyklý. Jen mám teď problém s tím částečným checkoutem, v případě webserveru, kde potřebuji na server nahrávat pouze adresář se zdrojákem.
-
... Takže by mi stačilo něco jako má SVN svn export (pokud si dobře vzpomínám), kdy dojde k vytvoření kopie požadovaného adresáře bez .svn dat...
Jen kdyby to šlo přímo na serveru kde chci data nahrávat.
Když pominu to že deployment aplikace by se skutečně měl dělat jinak (jak to radí ostatní), tak
to co hledáš je git archive
git archive --format tar --remote ssh://server.org/path/to/git HEAD docs/usage | tar zxf -
Ano, toto sice je něco jako svn export, ale potřeboval bych aby se to dělalo tam, kde chci data nahrát. Tedy logicky spíše něco jako svn import.
Podle toho, kolik lidí se mi snaží pomoc se domnívám, že to co potřebuji GIT neumožňuje. Přesto mě zaujala rada od Ovrscouta kde radí něco na způsob vnořených repozitářů.
Jak se to dá realizovat, aniž by bylo to, co je ve vnořeném repozitáři, verzováno dvakrát?
-
Pokusím se nastudovat submoduly (http://stackoverflow.com/questions/1871282/nested-git-repositories).
-
... Takže by mi stačilo něco jako má SVN svn export (pokud si dobře vzpomínám), kdy dojde k vytvoření kopie požadovaného adresáře bez .svn dat...
Jen kdyby to šlo přímo na serveru kde chci data nahrávat.
Když pominu to že deployment aplikace by se skutečně měl dělat jinak (jak to radí ostatní), tak
to co hledáš je git archive
git archive --format tar --remote ssh://server.org/path/to/git HEAD docs/usage | tar zxf -
Ano, toto sice je něco jako svn export, ale potřeboval bych aby se to dělalo tam, kde chci data nahrát. Tedy logicky spíše něco jako svn import.
Omlouvám se za nepozornost - toto skutečně funguje jako svn import (kdyby existoval) a asi je to skutečně nejblíže tomu, co jsem hledal.
Koukal jsem na submoduly a to také není nic co by mi na řešení tohoto problému přišlo ideální.
-
Ak je to PHP tak tam by naozaj malo stacit len to git archive. Ono sa ten prikaz da pridat do git hooks. Ukazky su napriklad tu https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks
-
+1 Výstupem sestavení produktu by měl být balíček (.deb, .rpm, .war, .ear, .tar.gz atd.), který se pak nasazuje (na testy, do produkce). Zdrojáky tam nejsou potřeba resp. nepatří tam.
Z toho co píšete mi přijde, že GIT je určen pouze pro kompilované jazyky :D
Co třeba PHP? V takovém případě zdrojáky na server patří a export do .tar.gz mi moc užitečný nepřijde.
Jestli mám špatný už koncept používání verzovacího systému, rád se poučím, ale v tomto případě zatím nechápu co mi chcete říct.
Programuji ve více jazycích a už dlouho používám verzovací systém. Používal jsem SVN a teď se snažím přecházet na GIT. Vždy mám v projektu jak zdrojáky, tak podklady. Každý kdo na projektu pracuje potřebuje i podklady. Navíc ty se leckdy také verzují (návrhy DB, soubory s poznámkami atp.)
Vše funguje jak bych chtěl a jak jsem zvyklý. Jen mám teď problém s tím částečným checkoutem, v případě webserveru, kde potřebuji na server nahrávat pouze adresář se zdrojákem.
Zdrojáky jsem myslel celý obsah úložiště 1:1 přenesený na server. U skriptovacích jazyků se samozřejmě zdrojáky na server dostanou, ale podle mého není vhodné, aby byly v tom samém tvaru, jako v úložišti.
I u nekompilovaných jazyků se často nějaké zpracování dělá – generování kódu, skládání více souborů do jednoho (CSS, JavaScript, obrázky atd.), konverze (např. ze SVG nebo XCF do PNG). Já např. generuji i některé shellovské skripty, protože mi to ušetří práci a udržuje to samo program konzistentní (jedna informace je uložená jen na jednom místě – i když se pak použije třeba ve dvou programovacích jazycích).
-
+1 Výstupem sestavení produktu by měl být balíček (.deb, .rpm, .war, .ear, .tar.gz atd.), který se pak nasazuje (na testy, do produkce). Zdrojáky tam nejsou potřeba resp. nepatří tam.
Z toho co píšete mi přijde, že GIT je určen pouze pro kompilované jazyky :D
Co třeba PHP? V takovém případě zdrojáky na server patří a export do .tar.gz mi moc užitečný nepřijde.
Jestli mám špatný už koncept používání verzovacího systému, rád se poučím, ale v tomto případě zatím nechápu co mi chcete říct.
Programuji ve více jazycích a už dlouho používám verzovací systém. Používal jsem SVN a teď se snažím přecházet na GIT. Vždy mám v projektu jak zdrojáky, tak podklady. Každý kdo na projektu pracuje potřebuje i podklady. Navíc ty se leckdy také verzují (návrhy DB, soubory s poznámkami atp.)
Vše funguje jak bych chtěl a jak jsem zvyklý. Jen mám teď problém s tím částečným checkoutem, v případě webserveru, kde potřebuji na server nahrávat pouze adresář se zdrojákem.
Zdrojáky jsem myslel celý obsah úložiště 1:1 přenesený na server. U skriptovacích jazyků se samozřejmě zdrojáky na server dostanou, ale podle mého není vhodné, aby byly v tom samém tvaru, jako v úložišti.
I u nekompilovaných jazyků se často nějaké zpracování dělá – generování kódu, skládání více souborů do jednoho (CSS, JavaScript, obrázky atd.), konverze (např. ze SVG nebo XCF do PNG). Já např. generuji i některé shellovské skripty, protože mi to ušetří práci a udržuje to samo program konzistentní (jedna informace je uložená jen na jednom místě – i když se pak použije třeba ve dvou programovacích jazycích).
A ještě je potřeba dodat, že součástí úložiště jsou často další nástroje pro podporu vývoje a ty na produkčním systému rovněž nemají co dělat. Pokud je pro tebe CI/CD server overkill (což může být, zvláště pokud jsi sám), nic nebrání tomu vytvořit si vlastní deployment skripty u sebe (ať už v shellu nebo nějakém nástroji pro to určeném, výběr je veliký). Osobně si už neumím představit neautomatizovaný deployment. Ale posílat na produkční server raw git repozitář není dobrá myšlenka.
-
Z toho co píšete mi přijde, že GIT je určen pouze pro kompilované jazyky :D
Co třeba PHP? V takovém případě zdrojáky na server patří a export do .tar.gz mi moc užitečný nepřijde.
A na to jsi prisel jak? Git je na spravu verzi, CI na integraci.. I v tom pitomem PHP preci nebudes kopirovat na server zdrojaky vcetne testu a budes to chtit udelat az pote, co ti prosly jednotkove i integracni testy, ne? Nemluve o tom, ze i to nasazeni PHP neni jenom nakopirovani souboru, ale muze obsahovat trebas databazove migrace, minifikace css..
-
Git submoduly jsou víceméně vnořená repository s trochou té omáčky navíc, tj. dá se pak použít git submodule pro spuštění akcí nad všemi i vnořenými repository. Pokud toto nepotřebujete či nechcete můžete prostě spustit ve vnořeném adresáři git init . a vytvořit v něm repository a v něm pak verzovat samostatně. Jako bonus můžete ale nemusíte toto vnořené repository sledovat v tom vnějším.
Git má
Někdy může být problém, pokud už máte soubory podadresáře ve vnějším gitu zaverzované ale dál je chcete mít v samostatném repository(tj v předchozích commitech zůstanou ale v dalších už se k nim budete tvářit jako k jinému repository).To lze řešit třeba dočasným přesunutím podadresáře pryč a vytvoření commitu ve kterém tyto soubory odeberete z gitu. A pak vložíte podardresář zpět tentokrát už s vytvořeným repository. Ale myslím že toto nebyl váš původní požadavek.
Zkuste si s tím pohrát a uvidíte.
Jinak, omlouvám se pokud už to znáte, dobrá kniha o základech gitu je Pro-Git v https://git-scm.com/book/en/v2 (https://git-scm.com/book/en/v2) nebo v docela slušném překladu na [url]http://knihy.nic.cz[url] . Je to už trochu postarší kniha a git zas ušel kousek kupředu, ale prvních pár kapitol určitě stojí za přečtení pro pochopení základů jak to funguje a co od toho můžete očekávat.
-
Jinak, omlouvám se pokud už to znáte, dobrá kniha o základech gitu je Pro-Git v https://git-scm.com/book/en/v2 (https://git-scm.com/book/en/v2) nebo v docela slušném překladu na [url]http://knihy.nic.cz[url] . Je to už trochu postarší kniha a git zas ušel kousek kupředu, ale prvních pár kapitol určitě stojí za přečtení pro pochopení základů jak to funguje a co od toho můžete očekávat.
Ano, tuto knihu znám a hodně informací o GITu mám právě z ní. Přesto děkuji :)
-
Z toho co píšete mi přijde, že GIT je určen pouze pro kompilované jazyky :D
Co třeba PHP? V takovém případě zdrojáky na server patří a export do .tar.gz mi moc užitečný nepřijde.
A na to jsi prisel jak? Git je na spravu verzi, CI na integraci.. I v tom pitomem PHP preci nebudes kopirovat na server zdrojaky vcetne testu a budes to chtit udelat az pote, co ti prosly jednotkove i integracni testy, ne? Nemluve o tom, ze i to nasazeni PHP neni jenom nakopirovani souboru, ale muze obsahovat trebas databazove migrace, minifikace css..
Pokud je na nasazování PHP nějaký jediný správný způsob, tak ten asi bohužel neznám.
Já v případě PHP většinou opravdu jen kopíruji zdrojáky na server. Pokud jsou potřeba úpravy databáze, tak je dělám ručně a pak jen nakopíruji soubory. V repozitáři mám právě adresářovou strukturu takovou, že jen jeden adresář patří na server a to kompletně a naopak žádný jiný tam nepatří (záznamy o změnách v DB, podklady atp.). Na všech vývojových strojích mám kompletní repozitář a vyvíjím na lokále a až je všechno otestované a připravené, tak soubory nakopíruji na server.
Nicméně rád bych se vyhnul diskuzi na téma "hloupé PHP", "špatný deployment" atp. Zajímalo mě pouze to, co je popsáno v úvodním postu a přestože to není ideální, tak git archive --remote je pro mě asi nejvhodnější.