Diskuze: Git - vývoj produktů nad jedním základem
Martin Dráb:19.5.2021 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.
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_programator). Cili, drzet tam od kazdeho programatora jeho verzi
zvlast.
Martin Dráb:20.5.2021 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í.
Zobrazeno 14 zpráv z 14.