reklama

Několik nejasností začátečníka s Gitem

Několik nejasností začátečníka s Gitem
« kdy: 27. 03. 2019, 09:55:20 »
Ahoj,
pročetl jsem "Pro Git / Scott Chacon" a pár tutoriálů, základní princip verzování a větvení snad chápu, ale trochu se ztrácím v obecném workflow..

Jedna z věcí, kterou potřebuju je centrální úložiště. Část věcí píšu doma, něco v práci, občas je potřeba dělat odkudkoliv na tom co zrovna hoří... A ne vždy je praktické/možné přenášet všechno sebou.
Takže v práci dělám na projektu A, udělám commit a push na GitHub. Doma pak stáhnu a pokračuju v práci.
Dejme tomu bude potřeba udělat zásah do strého projektu, doma stáhnu, udělám opravy, push na GitHub. Ovšem v práci pak zjistím, že před X měsíci jsem tohle už taky řešil a jen nenahrál na server. Jde to sloučit, nebo jak na to Git upozorní - předpokládám, že zařve a je to rozumně řešitelné.

Nebylo by lepší na vývoj z domu mít druhý účet a skládat to jako od dvou vývojářů? Má to nějaké výhody, nebo je to úplný nesmysl?

A nakonec, u webových projektů, se mi prostě nelíbí představa mamutí složky .git na webserveru. Jistě, můžu zakázat přístup do složky, ale... Navíc jak správně řešit když samostatně vyvíjím např. knihovnu pro DB, prezentační vrstvu (hromada SASSy šablon + kompilované styly), hodilo by se spíš řešit Git pro jednotlivé komponenty a pak jenom poskládat hotový projekt z aktuálních verzí. Jak k tomu přistupovat? Nebo prostě .git pro každý web a případné knihovny prostě kopírovat...
PMD85 -> Didaktik Gama -> PC XT -> ... x86/x51/ARM
Basic -> Turbo Pascal -> C++ -> Turbo ASM -> C# -> PHP -> Bash :-)

reklama


Re:Několik nejasností začátečníka s Gitem
« Odpověď #1 kdy: 27. 03. 2019, 10:31:08 »
Jedna z věcí, kterou potřebuju je centrální úložiště. Část věcí píšu doma, něco v práci, občas je potřeba dělat odkudkoliv na tom co zrovna hoří... A ne vždy je praktické/možné přenášet všechno sebou.

Ano presne na toto je git a podobne systemy idealni nastroj

Takže v práci dělám na projektu A, udělám commit a push na GitHub. Doma pak stáhnu a pokračuju v práci.
Dejme tomu bude potřeba udělat zásah do strého projektu, doma stáhnu, udělám opravy, push na GitHub. Ovšem v práci pak zjistím, že před X měsíci jsem tohle už taky řešil a jen nenahrál na server. Jde to sloučit, nebo jak na to Git upozorní - předpokládám, že zařve a je to rozumně řešitelné.
Tak záleží co je myšleno tím ne-nahrál na server, pokud byla práce v gitu (vše bylo commitnuto) a jen to nebylo pushnuto na server, tak se stím v závislosti na tom jak velké to byly změni git docela dobře popere, pokud člověk používá například pro práci s git i nějaké IDE či grafickou nástvbu, tak řešení případných konfliktů bývá poměrně bezbolestné.

Nebylo by lepší na vývoj z domu mít druhý účet a skládat to jako od dvou vývojářů? Má to nějaké výhody, nebo je to úplný nesmysl?
Tady nevidím moc důvod proč si to tak komplikovat, mít více ůčtů (forků) má zejména význam pokud na projektu dělá více lidí a je třeba jejich práci revidovat a schvalovat před začleněním.

Pokud na projektu pracuje člověk sám, tak nevidím důvod proč si vytvářet fork. Obocně se snažím na jakoukoliv sadu změn vytvářet si vlstní větev a tu pak případně začlenit do hlavní větve.

A nakonec, u webových projektů, se mi prostě nelíbí představa mamutí složky .git na webserveru. Jistě, můžu zakázat přístup do složky, ale...
Tak ono není důvod mít .git součástí těch projektů na serveru, je to jen o způsobu deploy. Osobně bych doporučoval mít nějaký nástroj skript (gitlab má podporu pro deploy), který zajistí nahrání dané verze projektu na dané umístění.

Navíc jak správně řešit když samostatně vyvíjím např. knihovnu pro DB, prezentační vrstvu (hromada SASSy šablon + kompilované styly), hodilo by se spíš řešit Git pro jednotlivé komponenty a pak jenom poskládat hotový projekt z aktuálních verzí. Jak k tomu přistupovat? Nebo prostě .git pro každý web a případné knihovny prostě kopírovat...

Tady záleží na preferencích, někdo preferuje monolitický přístup někdo zase ne. Osobně to řeším tak že mám hlavní repositář a jednotlivé komponenty mají vlastní git a jsou začleněny jako git submoduly do toho hlavniho git projektu. Jednotlive verze projektu pak maji specifikovan presne verze jednotlivych submodulu/komponent

Re:Několik nejasností začátečníka s Gitem
« Odpověď #2 kdy: 27. 03. 2019, 10:31:22 »
V podstate je jde jen o merge ruznych vetvi. Jestli to je na lokale, na ruznych git serverech je nakonec jedno, na konci pujde o merge dvou ruznych vetvi. V nejhorsim stavu budes muset rucne fixnout co automaticky merge nezvladnul.

Re:Několik nejasností začátečníka s Gitem
« Odpověď #3 kdy: 27. 03. 2019, 10:59:14 »
Dejme tomu bude potřeba udělat zásah do strého projektu, doma stáhnu, udělám opravy, push na GitHub. Ovšem v práci pak zjistím, že před X měsíci jsem tohle už taky řešil a jen nenahrál na server. Jde to sloučit, nebo jak na to Git upozorní - předpokládám, že zařve a je to rozumně řešitelné.
Záleží na tom, jestli tu změnu máte commitnutou nebo ne, v jakém branchi a jestli tam máte i jiné změny. Pokud vyvíjíte sám, asi nebudete moc používat branche, budete úpravy průběžně commitovat a průběžně synchronizovat s „centrálním“ repository – pak takovýhle případ nemůže nastat. Může nastat případ, že budete mít na obou místech různý poslední commit (nebo několik posledních commitů). Pak na jedné straně dáte push commitů do centrálního repository, na druhé straně dáte pull a řeknete, co se má udělat se změnami – buď rebase, který dá ty vaše commity bokem, stáhne branch ze vzdáleného repository a pak ty vaše commity, co dal bokem, přeskládá, jako by vznikly až na konci toho vzdáleného branche. A nebo zvolíte řešení změn pomocí merge, který ponechá ty dvě větve tak jak jsou, a na konci je jedním commitem spojí do jedné větve.

Nebylo by lepší na vývoj z domu mít druhý účet a skládat to jako od dvou vývojářů? Má to nějaké výhody, nebo je to úplný nesmysl?
Z hlediska workflow a práce s commity git nijak neřeší, zda je to od jednoho vývojáře nebo od více. Z pohledu gitu je to tak, že prostě máte dva různé commity, které chcete dostat do jednoho repository. Protože upravují ten stejný soubor, je potřeba vyřešit případné konflikty – jednoznačné věci git zvládne vyřešit sám, a pokud by tam byl skutečný konflikt, tj. různé varianty kódu, budete konflikt muset vyřešit ručně.

A nakonec, u webových projektů, se mi prostě nelíbí představa mamutí složky .git na webserveru. Jistě, můžu zakázat přístup do složky, ale... Navíc jak správně řešit když samostatně vyvíjím např. knihovnu pro DB, prezentační vrstvu (hromada SASSy šablon + kompilované styly), hodilo by se spíš řešit Git pro jednotlivé komponenty a pak jenom poskládat hotový projekt z aktuálních verzí. Jak k tomu přistupovat? Nebo prostě .git pro každý web a případné knihovny prostě kopírovat...
Na webovém serveru byste neměl vyvíjet, takže mít tam složku .git je zbytečné. Ani byste neměl řešit aktualizaci zdrojáků na serveru přes git – aktualizace v gitu není atomická, tj. v průběhu aktualizace byste měl některé soubory nové a některé staré, takže by aplikace nejspíš nefungovala správně.

Lepší je mít v rámci vývoje nějakou fázi „sestavení aplikace“, která posbírá potřebné soubory, případně je upraví (mimifikuje, zkomprimuje, validuje apod.) a sestaví z toho distribuční balíček, který nahrajete na webový server. Balíček tam rozbalíte do nového adresáře a pak přesměrujete symbolický link ze staré verze na novou. Tím přesměrujete aplikaci atomicky ze staré verze na novou – v jednom okamžiku se ještě používá stará, v dalším nová. Samozřejmě to neřeší případ, kdy si webový prohlížeč stahuje různé soubory (může stáhnou jeden skript ze staré verze a další z nové), ale to se zase řeší jiným způsobem (obvykle verzováním skriptů a stylů). Díky tomu symlinku také máte možnost vrátit se hned zpět k předchozí verzi, pokud by se ukázalo, že v té nové je chyba.

Re:Několik nejasností začátečníka s Gitem
« Odpověď #4 kdy: 27. 03. 2019, 11:51:31 »
Git je decentralizovaný verzovací systém, za push do „centrály“ zodpovídáte sám, stejně jako za pull před započetím práce. Jinak můžete mít změny rozeseté různě na počítačích a časem to budete muset řešit. Sice to lze, ale při nahromadění změn to rozhodně příjemné není.

Například jiný systém fossil umožňuje autosync, kdy ve vhodných chvílích (commit, tag, branch, ...) automaticky se stáhne seznam změn ze vzdáleného repositáře a před commitem do větve, jejíž aktuální verze nebyla začleněna do vašeho pracovního adresáře, hlásí varování a nabízí vytvoření nové branche. Což většinou nechcete, takže uděláte opatrně merge s vaší aktuální verzí a pak teprve uděláte commit a (při zapnutém autosync) se už pushne samo. Případně si změny uložíte bokem pomocí stash, uplatníte všechny potřebné změny ze vzdáleného repositáře a pak svoje změny ze stash zase obnovíte a provedete commit (výsledek bude stejný).

Pozastavil bych se nad tím, co je „zásah do ostrého projektu“. Ostrý projekt bude nejspíš větev (jejíž případné commity budou opatřeny release tagem - označením verze). Změny můžete provádět nejspíš ve „feature větvích“ které pak začleňujete do ostré větve (nebo ve zjednodušeném schématu máte jen jednu „vývojovou nestabilní větev“, kde změny provádíte a odkud je čas od času začleníte do ostré větve). Pak - pokud používáte git k deploy na provozní server - se nemůže stát že nemáte změnu správně začleněnou v repositáři.

Zda provádíte deploy pomocí git nebo buildovacího nástroje je ba vás. Pokud aplikaci sestavujete buildovacím nástroje, budete používat nejspíš nasazení sestavené aplikace a v repositáři budete mít jen kód, nikoli sestavení. Pokud nasazujete rovnou kód (často u php...) pak můžete použít verzovací systém (pokud nevadí ta krátkodobá nekonzistence). Pokud používáte databázi, musíte taky verzovat databázové schéma, což je samostatné téma :-)

reklama


Re:Několik nejasností začátečníka s Gitem
« Odpověď #5 kdy: 27. 03. 2019, 12:17:42 »
Díky všem  :)

info kolem deploy je pro mě novinka a jdu dál hledat, to začíná docela dávat smysl.
Git jako submoduly hlavního projektu zní zajímavě - nebyl by nějaký link na další studium?...

PS: O gitu na web serveru samozřejmě uvažuju pouze lokální vývojový, určitě ne na ostrém, ale i tak je to lepší řešit jinak.

Zamlouvá se mi myšlenka mít jedno (lokální) úložiště git projektů a provádět deploy podle umístění. Zatím je to pro mě ještě velká neznámá... Splácnout něco v Bashi problém není, ale asi to není ta správná cesta...
PMD85 -> Didaktik Gama -> PC XT -> ... x86/x51/ARM
Basic -> Turbo Pascal -> C++ -> Turbo ASM -> C# -> PHP -> Bash :-)

Re:Několik nejasností začátečníka s Gitem
« Odpověď #6 kdy: 27. 03. 2019, 13:03:10 »
Zalezi co vyvijis(jazyk/ekosystem). Ja jsem napriklad jeden cas se submoduly laboroval, ale nakonec composer/yarn to resi za me.
ohledne deploy mrkni na "continuous integration". v podstate jde o to, mit nejaky nastroj diky kterymu v repo mas napr. scss (takze css je v .gitignore) a naopak v "buildu" (tez nekdy oznacovany jako "artefact") zase nemas scss a mas jen css. to same napr pro vendor ci node_modules pokud se bavime kolem webu.
Děkuji za možnost editace příspěvku.

Re:Několik nejasností začátečníka s Gitem
« Odpověď #7 kdy: 27. 03. 2019, 15:56:49 »
Pokud s gitem začínáte, submodulům bych se raději vyhnul. Nepoužívá se to zas tak často, takže k tomu není moc dokumentace a praktických příkladů, nemusí to podporovat všechny nástroje. Používá se to hlavně tehdy, když už máte nějakou infrastrukturu a postupy nějak nastavené, chcete v tom začít používat Git (beze změny té infrastruktury a postupů), a zároveň je projekt tak velký, že by bylo problematické mít ho celý jako jeden projekt. Myslím, že to používá např. Microsoft pro zdrojáky Windows. Pokud s gitem začínáte, udělejte si samostatné repository na každý projekt – ušetříte si tím spoustu starostí.

Re:Několik nejasností začátečníka s Gitem
« Odpověď #8 kdy: 27. 03. 2019, 17:25:38 »
Jinak submodul by mel splnovat nasledujici podminky:
1. Submodul je zaroven samostatnym plnohodnotnym projektem (jako napriklad knihovna). Pokud ne, tak submodul nevytvarim, ale pouziju obycejny adresar v hlavnim projektu
2. Pro sestaveni hlavniho projektu potrebuju zdrojaky submodulu. Pokud mi staci pouze produkt sestaveni submodulu (napriklad jarko), tak submodul nepouziju a pouziju napriklad maven (nebo jeho ekvivalent, zalezi na pouzitym jazyce)

Malokdy jsou obe podminky splneny, v praxi, jak uz bylo receno, submoduly se pouzivaji malokdy

Re:Několik nejasností začátečníka s Gitem
« Odpověď #9 kdy: 27. 03. 2019, 19:44:11 »
Zatím mám hodně daleko do toho, abych se v Gitu pokoušel o něco složitějšího, ale je rozhodně dobré vědět o dalších možnostech.
U webových projektů to vidím reálněji na ten composer. Pro ostatní jazyky si bohatě vystačím se základem.
PMD85 -> Didaktik Gama -> PC XT -> ... x86/x51/ARM
Basic -> Turbo Pascal -> C++ -> Turbo ASM -> C# -> PHP -> Bash :-)

 

reklama