Ahoj, git zvládá větve a merge v pohodě, stejně nebo lépe než ostatní verzovací systémy. Asi děláš něco špatně :) Nebo ten kód při každé změně natolik překopeš, že to prostě mergnout nejde?
Nauč se s gitem pracovat v příkazové řádce. Podle mých zkušeností lidi, kteří používají GUI, se to prostě pořádně nenaučí a dělají chyby. Pro snadný přenos jednotlivých změn mezi větvemi slouží git cherry-pick (pokud samozřejmě není vhodné dělat merge). Petr Messner > 17. 10. 2020 v 18:24, [email protected] <[email protected]>: > > Ahoj, moc díky. > > GIT jsem si prošel jako videa na YT a používám, je to velice jednoduchý > nástroj. Mám nějaká GUI klikátka, díky čemuž se v něm lze hezky vyznat a > rychle se vracet v čase. V podstatě s GIT (protože dělám sám) mám jediný > problém: větve. Ale to je utrpení! Jakmile potřebuji rozdělat práci ve dvou > větvích, tedy budu logicky jednoho dne spojovat, je to cesta do pekla. > Kdykoliv mi GIT udělá merge, je to něco jako hodit nový kód do mixéru a něco > vypadne. Někdy ignoruje kód z jedné větve, někdy z druhé, migrace už ani > neřeším (dneska si už ani netroufnu mít změny 1 modulu ve dvou větvích). > Testováním a skládáním modelů z obou větví někdy strávím hodně času a je > třeba projekt komplet přetestovat, udělat nový commit a pak zase chvíli se > zdviženým čelem pokračovat. Už jsem i raději kód napsal znovu a díky stroji > času v PyCharm kopíroval části kódu do nového commitu. Občas jsem potřeboval > určitý stav větve přenést do jiné a, pak rebase, výsledkem byla už úplně jiná > aplikace, ale nezjistil jsem, co má dělat :) > > Zkusil jsem každého klienta vést jako vlastní větev, vypadalo to krásně, než > jsem potřeboval vzájemně prohazovat funkčnosti. Myslím, že i cestování časem > má lidstvo lépe zdokumentované, než co já dostal za výsledek :). Ale to jsou > ty větve, nesmí se holt mixovat. Aktuálně tedy jedu projekty odděleně a pokud > si vzpomenu, že něco mám hotové u jiného klienta, copy&paste je sice trapné, > ale mám to pod kontrolou a funkční. Celková časová náročnost je vyšší, ale > čas se vrací, že nemusím "uklízet" a testovat po GITu a jeho merge. > Základní/společné moduly pak jedou společně, tam není co zkazit, snad jen, > občas bych si nějaký kód potřeboval "odložit", neboť zastaral a už ho asi > nepoužiji, ale chci mít možnost o něm vědět a případně ho rychle nalézt, na > to jsem v GITu nenašel jiné řešení než vlastní větev s "odpadem", takže to > držím jako odkomentovaný kód. > > Každopádně díky za názory, bylo to velice poučné. Trochu mě mrzí, že Django > toto neřeší nějak systematičtěji. Snad časem GIT bude mít funkce tímto směrem > a o to systematičtěji se o to půjde postarat. Standa > > >> On Sunday, 13 September 2020 at 15:19:16 UTC+2 Vláďa Macek wrote: >> Ahoj Stando, rozumím. Pamatuju si sám sebe v minulosti. :-) >> >> Nebuď ostražitý ke gitu. It's like UNIX - user friendly, just selective >> about who its friends are. :-) >> >> Programátor se gitu nevyhne. Čím dřív se ho pořádně naučíš, tím líp. Ano, >> řádkový klient je z hlediska UX blbě navržený, místy neintuitivní. Ale celý >> je to stabilní a pomáhá to. Jen věnuj víc energie a času jeho používání. >> Bohatě se ti učení vrátí. >> >> Tím neprosazuju svojí variantu d) níž. Byla by funkční, ale je neobvyklá a >> jen pro někoho. Uvedl jsem ji jako možnost. >> >> Hlavní pro tebe je udržovat minimum rozdílů mezi verzemi, protože "bolesti" >> tvojí hlavy, kterou ti jejich TRVALÁ údržba způsobí, ti žádný klient nebude >> chtít zaplatit. >> >> Nad každou výhybkou dobře přemýšlej, než jí zavedeš. Budeš s ní žít ty, ne >> klient. Velmi pomáhá mít zavedenou diskusi s klienty a tak, abyste spolu >> jednali jako partneři. Dokázat umravnit nebo i odmítnout klienta, který >> odmítá pochopit, že něco mít nebude nebo to bude mít draho, i když jemu to >> připadá easy a je to přece technicky zvládnutelné. >> >> V. >> >> On 12. 09. 20 12:20, Stanislav Vasko wrote: >> > Díky za podrobnou odpověď. Spoléhat na GIT se bojím, už jsem si s ním >> > užil. Asi nejlépe mi zatím vychází ty výhybky (zatím). Dám si do settings >> > jméno klienta a podle toho si udělám změny. Líbí se mi, že to budu mít >> > pohromadě, ale dlouhodobě a při více klientech/změnách to bude asi dost >> > hokej. >> > >> > Moduly ad klient budou cesta, jakmile do toho někdo slápne více, zbytek >> > poběží na "base". Dokumentace je základ, to je základ, píšu si i hromadu >> > poznámek do kódu, jinak bych se zbláznil. >> > >> > Díky, Standa >> > >> >> On 12 Sep 2020, at 02:11, Vladimír Macek <[email protected]> wrote: >> >> >> >> >> >> >> >> Ahoj, >> >> >> >> a) jedna z cest na začátku vývoje byla, že bys měl projekt koncipovaný >> >> jako multi-tenant, tzn. databáze a globální objekty (glob. objekty, >> >> cache, fajly, ...) by s izolací klientů počítaly. Pak bys to měl na >> >> jednu stranu jednoduché s údržbou. Bylo by ale neustále nutné hlídat tu >> >> izolaci a udržovat rozdíly ve funkčnostech. >> >> >> >> b1) Když by funkčních rozdílů mezi doménami bylo míň, můžeš vyvíjet >> >> JEDEN projekt pro všechny, provozovat pro každého klienta extra >> >> instanci, ale z JEDNOHO branche. Funkční rozdíly mezi doménami by se >> >> rešily výhybkami v kódu. >> >> >> >> Zdrojáky na serveru můžou být jen jednou, dokonce i virtualenv jen >> >> jeden, jen různé settings, databáze a file storage. >> >> >> >> b2) Větší funkční oddělený celek, by se dal uzavřít do apky, kterou by v >> >> INSTALLED_APPS měli jen příslušní klienti. Pozor, stále se z ní dá >> >> importovat. >> >> >> >> c) Silnější varianta je udržovat takovou per-instance apku jako >> >> separátně instalovanou jen do virtualenvu příslušného klienta. Pak by >> >> importovatelná nebyla, ale pro klienty bys již musel udržovat oddělené >> >> virtualenvy. >> >> >> >> Zde bych jit doporučil nástroj na automatický deployment, například >> >> Ansible. Nedávno jsem ho zavedl do svého toolsetu a je opravdu fajn. >> >> Deployneš novou verzi všem najednou, klidně s customizacemi. >> >> >> >> d) Může tě zaujmout ještě další varianta: Společnou část projektu bys >> >> udržoval v hlavním git branchi, třeba 'prod' (jako produkční). A pak bys >> >> pro klienta požadujícího změnu vytvořil branch 'prod-klient1', ve které >> >> by oproti 'prod' byly změny, které tento klient chtěl. >> >> >> >> Vývoj a bugfixy společných částí bys pushoval do 'prod' a hned mergnul >> >> do všech 'prod-*' branchů. Abys nezapomněl, můžeš si nastavit různé git >> >> hooky -- jen varovací nebo i blokující, že třeba nepushneš 'prod-*', >> >> pokud jsi do něj zapomněl mergnout 'prod'. >> >> >> >> Chce to jenom větší sebekázeň, ale git je na souběžný vývoj přímo >> >> dělaný. Výhody jsou, že git ti vždycky krásně zobrazí diffy mezi >> >> společnou verzí a klienty i mezi klienty navzájem. U žádného klienta >> >> není kód navíc. Nespolečné commity si navždy ponesou své messages, kde >> >> svému budoucímu já podrobně vysvětlíš, proč existují. To se u výhybek ne >> >> vždy daří. Viděl bych i omezený dosah chyb v 'prod-*' brenčích. Další >> >> výhoda mě napada, že když při mergi do 'prod-*' dojde někde k průniku >> >> změn (nechci říkat přímo kolizi), přiměje tě to k úvaze, jestli dělení >> >> funkčností koncipuješ dobře. >> >> >> >> Ansible ti opět na jediný příkaz deployne do virtualenvů všech klientů, >> >> každého z příslušného branche gitu. >> >> >> >> V každém případě si veď dokumentaci kdy, kdo, chtěl jakou změnu, proč ji >> >> chtěl, jak jsi s ním o úpravě diskutoval. Tvým zájmem je mít rozdíly v >> >> kódu mezi klienty co nejmenší. >> >> >> >> Měj se, ať to jde, >> >> >> >> Vláďa >> >> tel. 608 978 164 >> >> >> >> >> >> On 12. 09. 20 0:25, [email protected] wrote: >> >> >> >>> Zdravím, >> >>> >> >>> potřeboval bych poradit či navést na best-practice v Django, jak jeden >> >>> projekt nasadit pro více firem, ale tak, abych v čase mohl dělat >> >>> klientské modifikace. Aktuálně jsem vymyslel aplikaci a používají ji 2 >> >>> moji klienti. Django aplikace běží na nGinx a abych mohl obě aplikace >> >>> aktualizovat současně, na serveru jsem nalinkoval společné zdrojové >> >>> kódy (virtuál linkuje společné adresáře/aplikace). Vše běží, protože >> >>> každá aplikace má svou konfiguraci a svou databázi. Pokud aplikaci >> >>> vylepším, nahraju ji na 1 místo, restartuji server či oba virtuály a >> >>> oba klienti frčí na aktualizacích. >> >>> >> >>> Nicméně: jak nejlépe postupovat, pokud např. 1. firma bude chtít >> >>> nějakou změnu v šabloně, 2. firma například upravit či přidat celou >> >>> funkčnost. Rád bych udržel zdrojový kód jednotný s nějakými "odbočkami" >> >>> pro konkrétního klienta, ale nemohu najít jak nejlépe a nejsystémověji >> >>> se tomu postavit, aby projekt byl dlouhodobě spravovatelný, zvlášť >> >>> pokud by přibylo klientů. >> >>> >> >>> Věřím, že existuje nějaké systémové řešení, budu rád i za navedení či >> >>> odkaz na nějaký tutorial. Předem díky! >> >>> -- >> >>> -- >> >>> E-mailová skupina [email protected] >> >>> Správa: http://groups.google.cz/group/django-cs >> >>> --- >> >>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny >> >>> „django-cs“ ve Skupinách Google. >> >>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, >> >>> zašlete e-mail na adresu [email protected] >> >>> <mailto:[email protected]>. >> >>> Chcete-li tuto diskusi zobrazit na webu, navštivte >> >>> https://groups.google.com/d/msgid/django-cs/f508f99c-c9d9-46c4-9ce3-102506cd4634n%40googlegroups.com >> >>> >> >>> <https://groups.google.com/d/msgid/django-cs/f508f99c-c9d9-46c4-9ce3-102506cd4634n%40googlegroups.com?utm_medium=email&utm_source=footer>. >> >>> > > -- > -- > E-mailová skupina [email protected] > Správa: http://groups.google.cz/group/django-cs > --- > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny > „django-cs“ ve Skupinách Google. > Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete > e-mail na adresu [email protected]. > Chcete-li tuto diskusi zobrazit na webu, navštivte > https://groups.google.com/d/msgid/django-cs/94928c7b-29e6-4a51-b881-9f42c572fcb1n%40googlegroups.com. -- -- E-mailová skupina [email protected] Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google. Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu [email protected]. Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/D418C989-0531-4645-9196-5DE0985920B5%40gmail.com.
