Využij akce až 80 % zdarma při nákupu e-learningu. Více informací.
Pouze tento týden sleva až 80 % na e-learning týkající se Pythonu
python week
Avatar
Vakos
Redaktor
Avatar
Vakos:30. ledna 14:04

Ahoj, řeším problém, verzi projekt na gitu, kde si dělám vlastní CMS pro weby. Dělám to v .net core. Jak ideálně řešit, když bych chtěl tento systém využít na pro vývoj jednotlivých webů nad tímto cms s možností aktualizovat projekty pokud cms dojde do vyšší verze?
Asi nejjednodušší by bylo každý projekt mít v solo větvi a pak by tam proběhl jen nějaký rebase nad nejnovější verzí cms. Toto ale není ideální řešení a ideálně bych to chtěl mít oddělené, tak aby každý projekt měl vlastní repozitář. Jak se dá řešit tento problém pomocí gitu?

Editováno 30. ledna 14:05
Odpovědět
30. ledna 14:04
"Jediný způsob, jak dělat skvělou práci, je milovat to, co děláte. Pokud jste to ještě nenašli, hledejte dál. Ne...
Avatar
Vakos
Redaktor
Avatar
Vakos:19. května 15:15

Jak se v praxi řeší tento problém?

Nahoru Odpovědět
19. května 15:15
"Jediný způsob, jak dělat skvělou práci, je milovat to, co děláte. Pokud jste to ještě nenašli, hledejte dál. Ne...
Avatar
Martin Dráb
Redaktor
Avatar
Odpovídá na Vakos
Martin Dráb:19. května 15:43

Podle mě by bylo lepší vyvíjet CMS tak, aby jej bylo možné použít pro různé weby bez nutnosti provádět pro ně specifické úpravy ve sdíleném kódu. Resp. bys při každé změn musel úpravu udělat tak, aby CMS byl stále kompatibilní se všemi weby. Nemám zkušenosti s weby, ale s, řekněme, normální aplikací. Prostě ji vyvíjíme tak, aby se pro každého zákazníka dala u něho na místě dostatečně nastavit.

Pokud chceš mít každý web v jednom repozitáři, můžeš to tak udělat a tvůj CMS do těchto repozitářů dostávat jako submodul. Je s tím ale trochu více práce a je třeba být opatrný.

Editováno 19. května 15:43
Nahoru Odpovědět
19. května 15:43
2 + 2 = 5 for extremely large values of 2
Avatar
Vakos
Redaktor
Avatar
Odpovídá na Martin Dráb
Vakos:19. května 19:43

Když budu vyvíjet CMS, tak mám nějaký základ nad kterým budu stavět jednotlivé weby. Každý nový web tedy vznikne kopii (fork?) repozitáře nejnovější verze CMS. Nový web je pak vyvíjen v novém repozitáři. Problém který řeším, jak aktualizovat konkrétní web z čisté verze CMS. Toto se dělá pomocí merge? Nebo jaký by měl být správný přístup v tomto případě? Vyvíjet na několika větvích nechci, to je blbost..

Nahoru Odpovědět
19. května 19:43
"Jediný způsob, jak dělat skvělou práci, je milovat to, co děláte. Pokud jste to ještě nenašli, hledejte dál. Ne...
Avatar
Martin Dráb
Redaktor
Avatar
Odpovídá na Vakos
Martin Dráb:19. května 20:20

Já bych se právě ke GitHubové metodě (fork pro každý nový web) nepřikláněl, protože mi přijde, že tě to může navádět k tomu, že budeš změny, které by klidně mohly patřit do základu, budeš primárně dávat jenom do repozitáře webu, kde je potřebuješ. Tohle může být celkem normální postup -- uděláš featuru kvůli jednomu webu a později zjistíš, že by se ti vlastně hodila v základu (protože bys ji vlastně potřeboval i jinde). Musíš prostě dávat pozor, abys věci, co mohou být sdílené, necpal do webu, ale do CMS.

Nevidím moc problém v tom vyvíjet ve více větvích (každá pro jeden web), pokud si zavedeš jasná pravidla. Například taková, že ve větvi master (resp. main) budeš mít onen sdílený CMS základ a větve pro jednotlivé weby vždy vyvedeš z toho materu. Pokud pak např. do základu uděláš novou featuru a budeš ji potřebovat dostat do určitého webu, protě větev pro daný web posuneš nad aktuální master (rebase). Samotný merge (bez rebase) bych tady nedoporučoval. Ono je to svým způsobem ekvivalentní tomu postupu z prvního odstavce (tam také vlatně vyvíjíš ve více větvích, jen je každá v jiném repozitáři).

Nebo, jak jsem říkal, můžeš mít ten CMS základ jako submodul pro repozitář každého webu. Submodul je vlastně ukazatel na určitý commit v jiném repozitáři. Výsledek je takový,k že:

  • pokud děláš změny v CMS, děláš je v jeho vlastním repozitáři,
  • pokud děláš změny na webu, děláš je v jeho vlatním repozitáři,
  • pokud potřebuješ u nějakého webu použít novější verzi CMS (nové featury), posuneš onen ukazatel (submodul) na nový commit CMS repozitáře.

Nejpřirozenější mi tady přijde ten submodul, ale zase je s tím více práce a snadněji můžeš udělat nějaou chybu. Takže bych já osobně možná volil i vývoj ve více větvích (pro každý web jedna), pokud bych si neřekl, že se se submoduly pořádně naučím :-).

Ale jakým způsobem se zařídíš, je jenom na tobě. Může se klidně stát, že přejdeš od jednoho způsobu ke druhému. Na jednom projektu jsme sdílený kód umístili právě do submodulu, protože se ukázalo, že jej bude dobré sdílet s úplně jiným projektem (jiným repozitářem). Sloučení repozitářů těchto dvou projektů (které budou používat sdílený kód) nepřipadalo moc v úvahu, protože nad každým pracuje jiný tým lidí.

Na druhou stranu, u jiného projektu jsme začali se submoduly (asi pět repozitářů, jeden se přes submodul sdílel do ostatních). Ač toto řešení vypadlo velmi elegantně na papíře, v praxi se nám neosvědčilo a nakonec jsme prostě všechno hodili do jednoho repozitáře (na všem pracuje jeden tým, takže není třeba problém s oprávněními) a dá se říci, že každý má svoji práci ve vlastním adresáři (separace rolí je tady téměř dokonalá), plus samozřejmě existuje adresář pro sdílený kód.

Nahoru Odpovědět
19. května 20:20
2 + 2 = 5 for extremely large values of 2
Avatar
Vakos
Redaktor
Avatar
Odpovídá na Martin Dráb
Vakos:20. května 0:43

Osobně bych se chtěl vývoji v jednom repozitáři vyhnout. Moc se mi nelíbí celková přehlednost a odporuje to trochu i git-flow, což v plné verzi je na moje malé projekty až moc komplexní, ale třeba pro automatický deploy, který bych rád použil, je potřeba aspoň částečně využít tento přístup.

Líbí se mi myšlenka submodulů, které vypadají jako lepší alternativa k forkům. Teď jsem si to zkoušel a nevím, zda tomu úponě přesně rozumím. Do jednoho repozitáře si nahraji více repozitářů, kde jednotlivé soubory nějak upravuji. Poté se rozhodnu do kterého repozitáře změnu uložím. Jestli to výchozího, nebo v tom ve kterém aktuálně na projektu dělám. Funguje to takto nebo je ten přístup jiný?

Nahoru Odpovědět
20. května 0:43
"Jediný způsob, jak dělat skvělou práci, je milovat to, co děláte. Pokud jste to ještě nenašli, hledejte dál. Ne...
Avatar
Peter Mlich
Člen
Avatar
Peter Mlich:20. května 11:00

Jj, moduly je spravne reseni pro univerzalni veci. Jednotlive weby pak mas ve slozkach, jak jsi chtel a jen do configu pridas, jake moduly maji pouzit. Takze mas takove smisene reseni tvoji verze a univerzalni. jen si treba proste vybrat, ktera ta vec by se hodila mozna i jinde a udelat ji vic univerzalnejsi.
Na strance to take resi tak, ze mam treba 3 sloupce a pak bloky, ktere muzu umistit vpravo, vlevo, na stred. A pro kazdy te sloupec muze mit odlisne nastaveni. A jeste treba ma nejakou miniverzi. Treba blok s prihlasenim. na jednom webu chci zobrazovat nejake info, na jinem jen jmeno uzivatele.

Treba, cim mne nasi programatori webu zklamali (protoze tady valci sefove a kdo se dostane k moci, tak urci novy webovy portal, obvykle, protoze te druhe strane vyhovuje vice ten jejich), je prave nemoznost volby.
Z db nebo filesystemu ziskam nejaka data, tabulku (array, json / csv / xml). Treba nazev, popis, datum od-do, ... A nas svely system tato data umi zobrazit jen jedinou sablonou. Mne by se na spouste stranek hodilo pouzit jinou sablonu.
Nekde potrebuji aktualitu zobrazit jako

  • obrazek + nazev
  • datum + nadpis
  • datum + nadpis + popis...

A nebo treba mam seznam odkazu, souboru. Nekde chci zobrazit jen popisky a puntiky, jinde obrazky ikonky soubor. U seznamu odtazu zase podobne. Jenze pro seznam odkazu je sablona uplne strasna. Dela to 50% velikost pismen a pismena pouziva velka ABCD, a jsou tam ruzne cary a odsazeni zleva. No ty jo, na zabiti. Strasidelny vzhled.

 
Nahoru Odpovědět
20. května 11:00
Tento výukový obsah pomáhají rozvíjet následující firmy, které dost možná hledají právě tebe!
Avatar
Vakos
Redaktor
Avatar
Odpovídá na Peter Mlich
Vakos:20. května 11:39

Nevím jestli to plně chápu. Moc nechápu, proč by web měl jen jedinou šablonu. Aktuálně moduly chápu jako věc, která jde editovat a změny se buď nahrají do zdrojového repozitáře z kama modul je použit, nebo se změna aplikuje v aktuální repozitáři. To je na mě. Pak si myslím, že není problém používat více vzhledů. Při aktualizaci je akorát potřeba být opatrný u merge requestu.

Takto to zatím chápu a nevím jestli to chápu správně a není to jinak co se týče toho ukládání do jednotlivých repozitářů. V tomto systému mě hned napadne, co když udělám změnu, kterou vložím do aktuálního repozitáře, ale měla jít do repozitáře, který používám jako modul. Lze to nějak jednoduše řešit?

Nahoru Odpovědět
20. května 11:39
"Jediný způsob, jak dělat skvělou práci, je milovat to, co děláte. Pokud jste to ještě nenašli, hledejte dál. Ne...
Avatar
Peter Mlich
Člen
Avatar
Peter Mlich:20. května 13:31

Priznam se, ze Git nepouzivam. Takze se k tomu nechci moc vyjadrovat.

Ale resil bych to tak, ze mam jednu vetev app a potom jinou vetev pro klienty. A ti budou includovat app z hlavni vetve.

A nebo mit vetve s kopiemi app, ale nekdo musi v te vetsi chvalit, ze ma probehnout update. Tim padem by slo vratit klientovy zpet app, kdyz to nefunguje, na predchozi stav.

Nevim, jak funguji moduly v gitu, ale predstavuji si to neco jako samostane aplikace.
A tez nemam tuseni, jak se resi update databaze, kdyz treba je nutne pridat sloupec.
Co vim, tak je dobre drzet oddelene hlavni app a testovaci app a pak jeste verzi od kazdeho editora. Kazdy si muze vyvijet vlastni opravy a az mu to jede, tak je presune do testovaci verze. A z ni to pak presune po schvaleni aspon 2 osob, kteri si skutecne projdou kod :), nekdo do hlavni.

No, ale ja git nepouzivam, jen vyjimecne. Mne se nelibi cela ta myslenka pro rychlost vyvoje. Super, ze to savuje predchozi verze a je mozne hned prepnout na starsi. Ale zhlediska vyvoje potrebuji soubor nahrat na server a hned videt. Tohle zvladam na 3 klavesy a 1 klinuti mysi a vysledek vidi do 0.1s. Kdezto pres git je to strasna drbacka, klikacka, stale jen cekas a cekas :)
Resil jsem to tak, ze jsem mel lokalni verzi a v ni slozku presun_na_git. Verzoval jsem si to po svem, pozmenou pripony copy to *.1, *.2, *.3 .... Spoustel na localhost. A kdyz mi to jelo, tak jsem to presunul do slozky presun_na_git/ nejakym programem, co mi tam delal repository. A pak tim samym programem ven, na git, do testovaci vetve.
Je to takove krkolomne, ale mohl jsme vyvijet o neco rychleji, kdyz sem to stale neverzoval a nahraval jen konecnou verzi, az kdyz jsem chtel. Ale, nemel jsem program na serveru a tak sem musel spoustu veci opravovat kvuli rozdilnym verzim. Proto doporucuji tu slozku (presun_na_git/) presunout tez na git, jako treba (peter_progra­mator). Cili, drzet tam od kazdeho programatora jeho verzi zvlast.

 
Nahoru Odpovědět
20. května 13:31
Avatar
Vakos
Redaktor
Avatar
Odpovídá na Peter Mlich
Vakos:20. května 13:56

Zajímaly by mě hlavně zkušenosti s Gitem, jak to dělat správně, když budu používat nějaký přístup ... Ale díky za pomoc.

Osobně se mi git líbí i na malé projekty pro historii samotného vývoje, kdy jde vcelku jednoduše se vracet ke starším verzím a je v tom systém. Zároveň pokud se rozbije lokální verze, tak vcelku jednoduše se jde vrátit k poslednímu commitu. Pomalost vývoje v tom moc nevidím, commity je dobré dávat po nějaký logických celcích, ale pokud to nedodržíš, tak se zas tak nic nemusí stát. Nasadit na produkci buď můžeš manuálně, nebo třeba na githubu lze nastavit auto deploy, kde pokud řešení projde testy, tak to automaticky nasadí. Není to hned, ale když to dáváš na produkci, tak je ti jedno rychlost, ale spíše jestli je vše správně udělané.

Nahoru Odpovědět
20. května 13:56
"Jediný způsob, jak dělat skvělou práci, je milovat to, co děláte. Pokud jste to ještě nenašli, hledejte dál. Ne...
Avatar
Martin Dráb
Redaktor
Avatar
Odpovídá na Vakos
Martin Dráb:20. května 21:07

Mno, řekněme, že CMS budeš mít v repozitáři CMS a pak budeš mít dva weby, repozitáře WEB1 a WEB2. V CMS bude ten základ, prostě kód, který se používá v obou webech. Řekněme, že repozitáře budeš mít někde na serveru a budeš si je přes git clone stahovat k sobě.

Abys dostal CMS do webů, vytvoříš ve WEB1 a WEB2 složku shared a gitu řekneš, že se jedná o submodul (něco jako git submodule add ...), a to např. větev master repozitáře CMS. Git do té složky v podstatě naklonuje aktuální větev master z CMS -- pokud bys nevěděl, že shared je submodul, můžeš si klidně myslet, že je prostě součástí repozitářů WEB1 a WEB2.

Repozitář CMS si lokálně můžeš klidně naklonovat někam bokem a dělat v něm změny a posílat je na server. Aby se propsaly do submodulů, budeš to vždy muset gitu přikázat (git submodule update myslím). Můžeš také upravovat kód CMS přímo v rámci submodulu a odesílat ho na server. To moc nedoporučuju (ale možná je to tím, že jsem submoduly dostatečně nepoužíval), protože se tam můžeš potkat z dost neintuitivními věcmi. Vždy jsem radši měl ten CMS lokálně někde jinde jako samostatný repo a dával změny tam.

Nahoru Odpovědět
20. května 21:07
2 + 2 = 5 for extremely large values of 2
Avatar
Martin Dráb
Redaktor
Avatar
Odpovídá na Peter Mlich
Martin Dráb:20. května 21:14

No, ale ja git nepouzivam, jen vyjimecne....

Hm, to mi přijde nějaké hrozně překomplikované :-). Na tohle je ideální nějaký nástroj pro continuous integration / deploy, který ti každou změnu v repozitáři na serveru (push) propíše někam do testovacího webu. Pokud to znamená jen kopírování, bude to během pár vteřin (možná i dříve). Případně, pokud tomu nic jiného nebrání, můžeš mít klidně localhost nasměrovaný do lokálního repozitáře, takže každou změnu uvidíš opravdu hned (záleží, jak moc se zdrojáky kompilují).

Dnes už bych asi ve vílce lidech do projektu bez gitu (či potenciálně jiného verzovacího systému) asi nešel. Dokud je projekt malý, je to samozřejmě jedno, ale jakmile naroste, může natat opravdový horor :-).

Vracení se k předchozím verzím je k nezaplacení.

Nahoru Odpovědět
20. května 21:14
2 + 2 = 5 for extremely large values of 2
Avatar
Vakos
Redaktor
Avatar
Odpovídá na Martin Dráb
Vakos:21. května 1:08

Děkuji za rady. Už to chápu o trochu víc a díky radám jsem snad našel řešení, které zkusím používat. Dá se říct, že to bude vývoj jak na více větvích, který si popisoval. Rozdíl bude jen ten, že bude více repozitářů. V remotes mám přidané 2 projekty, tedy repozitář CMS a pak repozitář ve kterém vyvýjím. Pokud chci aktualizovat část s CMS, tak mohu na projekt použít buď Rebase, nebo Merge. Teď otázka. Co je lepší? Je lepší použít rebase, který mi změní historii a nebo merge? Je tady nějaké pravidlo kdy se hodí rebase a kdy merge?

Nahoru Odpovědět
21. května 1:08
"Jediný způsob, jak dělat skvělou práci, je milovat to, co děláte. Pokud jste to ještě nenašli, hledejte dál. Ne...
Avatar
Martin Dráb
Redaktor
Avatar
Odpovídá na Vakos
Martin Dráb:24. května 18:40

Pokud použiješ rebase správně, tak historii nezměníš (ne tam, kde by to byl problém). Rebase větve A nad větev B ti prostě uspořádá commity tak, že za všemi commity z A budou teprve následovat commity z B, takže historie A se nezmění. Pokud vím, tak merge lze pro tyhle případy také použít (přimergovat A do B), ale jsou tam nějaká omezení (fast forward only?). Záleží, jaký si nastavíš proces.

Nahoru Odpovědět
24. května 18:40
2 + 2 = 5 for extremely large values of 2
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 14 zpráv z 14.