Dotaz: zaciatok projektu: na zelenej luke

[exoskeleton]

dobry den,

sme mala developerska firmicka (3 ludia) a robime mobilne aplikacie. ako verzovaci nastroj pouzivame SVN. IDE Eclipse. Pre kazdu zakazku/projekt mame zvlast repozitar.

Dostali sme sa ku vacsiemu projektu ktory bude mat backend (asi tomcat), frontend (web), GUI (client). Client bude mat moznost pouzivat pluginy. Rad by som sa opytal aky zvolit model vyvoja a verzovania?

1) je nacase sa zamysliet nad Gitom?

2) drzat vsetko ako jeden projekt v Eclipse?

3) drzat vsetko v jednom repozitari a zvlast branche pre client/pluginy/web/backend?

4) rozdelit to na jednotlive projekty a mat zvlast repozitare?

dakujem

Odpovědi

[Sten]

1. Git bych doporučil pro cokoliv. V „nejhorším“ lze použít git-svn a server mít stále na SVN, ale pokud se naučíte s Gitem pracovat (a poznáte i webové nástroje jako GitLab), už se k SVN nebudete chtít vracet.
2. Určitě ne. Jsou to tři oddělené části, měly by mít (nejméně) tři Eclipse projekty. (Ale mohou být v jednou workspace; doporučuji workspace per repozitář, takže záleží na rozdělení dále.)
3. Větve podle projektů nedělejte, Git to nepotřebuje a dost to zhoršuje synchronizaci mezi projekty. Doporučil bych nastudovat Git-flow, které docela dobře vysvětluje, k čemu větve slouží, a doporučuje jeden způsob, jak je používat.
4. Jestli mít každý projekt jako samostatný repozitář nebo to mít v jednom, záleží hodně na tom, jak moc budou na sobě jednotlivé části záviset. Obecně bych dal dohromady backend+frontend (API mezi nimi asi nebude úplně stabilní, takže je vhodné držet dohromady odpovídající verze) a oddělil klienta (API by mělo být stabilní, jinak to zákazníkům rozbijete, takže to není vázané na konkrétní verzi serveru), ale i všechno dohromady by pro Git nebyl žádný problém.

[AraxoN]

1) je nacase sa zamysliet nad Gitom?

Čím skôr, tým lepšie. Marš na CZ.NIC a stiahni knihu Pro Git - veľmi Ti pomôže.

2) drzat vsetko ako jeden projekt v Eclipse?

Nie.

3) drzat vsetko v jednom repozitari a zvlast branche pre client/pluginy/web/backend?

Nie, branče slúžia na niečo úplne iné. Až prejdeš na Git tak to pochopíš. SVN Ti túto vedomosť nemal ako sprostredkovať.

4) rozdelit to na jednotlive projekty a mat zvlast repozitare?

Jeden repozitár nie je pre Git problém, ale SVN z toho dostane záhul (moja skúsenosť). Ak ale máš podprojekty, ktoré spolu súvisia len cez API, asi by som ich aj tak oddelil do samostatných repozitárov.

[exoskeleton]

rozhodli sme sa pre model projekt per repozitar. pricom budeme mat samostane projekty pre backend, frontend, klient, pluginy. a vsetko to bude v jednom Eclipse workspace pre lepsiu orientaciu.

budeme sa chvilu hrat s gitom a uvidime ci premigrovat vsetky doterajsie projekty alebo nie, predsa len drzat 2 verzovacie systemy pre malu firmicku je overkill.

dakujem za rady aj za tip na knihu o Gite v zrozumitelnom jazyku :).

[Sten]

Doporučuji mít workspace per repozitář, hodně to zjednodušuje správu nastavení pro ten workspace. Pokud vám víc vyhovuje mít všechno v jednom workspace, bude lepší to mít i v jednom repozitáři, problémy s konflikty při práci různých lidí na různých částech v Gitu na rozdíl od SVN nejsou (z podstaty distribuovaného VCS). Rozdělit existující repozitář je v případě potřeby docela snadné, sloučit rozdělené repozitáře je hodně těžké. (Stejně jsme postupovali i u nás, když se přecházelo ze SVN na Git, každá část měla svůj repozitář. O dva roky později jsme to pracně slučovali, protože se s tím pracovalo hrozně blbě, závislosti to při přepínání větví neustále rozbíjely a webové nástroje si s tím nedokázaly poradit.)

[Kit]

"workspace per repozitář" - OK, nemám námitek.

Co se myslí tím rozbíjením závislostí při přepínání větví? Rozhrani mezi moduly by mělo být neměnné, resp. může se pouze rozšiřovat.

[Michal Kubeček]

Co se myslí tím rozbíjením závislostí při přepínání větví?

Pokud budete mít podprojekty v samostatných repozitářích, bude těžké udržet přehled o tom, který snapshot podprojektu A je kompatibilní s kterým snapshotem podprojektu B. Pro posloupnost klasických release verzí se to ještě asi uhlídat dá, ale třeba při bisectu, kdy potřebujete přeložit a otestovat zcela obecné snapshoty, si to moc představit neumím.

Rozhrani mezi moduly by mělo být neměnné

To je chvályhodné předsevzetí, ale… Pane Smrtko, proč vy se pořád tak usmíváte?

[Kit]

Tak snad se v každém projektu uvádí, kterou minimální verzi jiného podprojektu vyžaduje. Také existují anotace "deprecated" a podobné mechanismy.

[Michal Kubeček]

Jak jsem už napsal, dokud se můžeme bavit o nějakém omezeném počtu verzí, tak to ještě jde. Tady se ale bavíme o gitu a jednotlivých commitech, kterých může být spousta a které ani nejsou lineárně uspořádané.

[Kit]

V Gitu existují také nějaké větve, z nichž většina do produkce prostě nejde. Kombinovat nějaké větve typu develop nebo dokonce feature prostě nemá význam.

Gitflow

[Sten]

V SVN je to jednoduché, revize rostou lineárně, takže pokud máte revizi 172 a podprojekt má napsáno, že vyžaduje 154+, tak by to mělo fungovat. Git ale nemá lineární historii, takže se nemůže číslovat lineárně, a pokud řeknete, že podprojekt vyžaduje commit aa725d4, tak není na první pohled jasné, jestli commit 57adf45 je jeho potomek (vyhovuje) nebo je to předek nebo třeba bratranec (nevyhovuje). Dá se to udržovat, ale je s tím spousta práce, a pokud nemáte silný důvod to rozdělovat hned na začátku (budete vyvíjet víc klientů, klient bude open source ap.), nerozděloval bych to. Rozdělit se to dá později.

[Kit]

K tomuto účelu se používají tagy.

Aby nedošlo k mýlce: Nevidím důvod, proč by se měl projekt uměle rozdělovat v místech, kde by mohla vzniknout silná závislost mezi moduly, ale spíš tam, kde by si různé týmy vývojářů mohly vzájemně lézt do zelí.

[Sten]

Poměrně často se nám stávalo, že při přepínání z master na různé release větve vývojář zapomněl přepnout všechny repozitáře, což pak mohlo mít za následek nefungující prostředí. Odhalí se to rychle, ale až po zkompilování a spuštění všeho, a to nějaký čas zabere, a je otravné na to muset pořád myslet (takže jsme pro to měli skript, který ale třeba při nekomitnutých změnách na některých repozitářích selhal a nastal stejný problém). Pak to dost ovlivňovalo CI server, někdo založil novou release větev, ale zapomněl nastavit všechny repozitáře, aby ji používaly, což nakonec může dostat do produkce i vadný produkt (Ci server otestuje místo nefunkčního releasu master, který projde). A takové věci jako merge/pull requesty jsou opravdu lahůdka, protože schvalující musí zkontrolovat změny ve všech repozitářích, než může změnu schválit. Pokud schválí změnu v jednom repozitáři, ale má potom výhradu ve druhém, klidně to může skončit ve stavu, kdy větev nefunguje. Nebo se může stát, že schválí změnu v jednom repozitáři, ale v dalším repozitáři mezitím někdo jiný schválí jinou změnu, dojde k merge conflictu, změna schválit nejde a zase je rozbitá větev.

[Kit]

Tak snad se vždy pracuje jen na kódu jednoho repozitáře, ne? Každý se kompiluje a testuje extra a každá změna se schvaluje také extra - nezávisle na ostatních repozitářích. Jinak to dělení do více repozitářů postrádá na významu.

Repozitáře prostě musí být na sobě zcela nezávislé.

[Sten]

To není tak jednoduché, pokud zavádíte nové vlastnosti. Znamená to zahodit agilní vývoj a vytvářet přesné specifikace, aby se vám nestalo, že v půlce vývoje, kdy už máte hotovou změnu na backendu, zjistíte, že na frontendu to vlastně takhle nemůže fungovat a rozhraní s backendem by mělo být jiné (v agilním vývoji to není problém, API se mění celou dobu, dokud není hotovo). A ano, v Gitu postrádá takové dělení smysl, v SVN je ale nezbytné, jinak si budou různí vývojáři blokovat práci, a tak spousta lidí přecházejících ze SVN do Gitu má tendence mít těch repozitářů co nejvíc.

[Kit]

Proto by rozhraní mělo být tenké, aby změna specifikace v jednom modulu neměla vliv na specifikaci v druhém modulu. Jinak to rozdělování nedává smysl a je lepší to nechat pohromadě.

Mezi dvěma commity by se také neměl modifikovat víc než jeden soubor a před commitem by měl projít testy.

[Sten]

Proč by se neměl modifikovat víc než jeden soubor? Je normální, že se v jednom commitu modifikuje několik souborů, třeba v Javě interface a implementace, v C++ hlavičkový a zdrojový souboru, mnohdy i dokumentace, testy nebo Makefile. Větší commity v kernelu modifikují klidně i desítky souborů. Případné merge conflicty budou stejně naprosto totožné, protože Git každý soubor merguje samostatně.

[Kit]

Když změníš více souborů, tak se blbě píše komentář, co jsi vlastně modifikoval. Pokud commituješ jen jeden soubor, tak se mnohem snáze "cestuje časem".

Nejdříve změním interface a postupně všechny jeho implementace. Hezky po jednom.

Dokumentace se nachází ve stejném souboru jako zdroják, takže i když ho změníš současně se zrojákem, je to stále změna v jednom souboru.

Modifikace Makefile stojí za zcela samostatný commit. Moc často se nedělá a je dobré, když je v historii dobře vidět.

Napsal jsem "neměl by", nikoli "nesmí". V SVN mnozí commitují jen 1× denně, což je špatně. V Gitu když uděláš commit 3× za minutu, tak je to stále v pohodě.

Většinou totiž dělám na jednom souboru (např. třídě), dokud ho nemám hotový. Do ostatních souborů přitom (zpravidla) nezasahuji. To snižuje i počty merge konfliktů.

[Sten]

Proč by se psal blbě komentář, co jsem modifikoval? Přijde ti třeba, že se tenhle komentář musel blbě psát? Je to jedna změna ve čtyřech souborech.

Mě se mnohem lépe cestuje časem, když při tom nemusím procházet každý jeden krok, jak se ty párky vyráběly. Ono stejně není nijak zajímavé, jestli se po změně interface napřed měnila tahle konkrétní implementace nebo nějaká jiná.

git log --stat u každého commitu vypíše, jaké soubory se měnily. Psát to do komentáře je zbytečné.

Pokud chci vidět modifikace Makefile, tak stačí zavolat git log Makefile (případně git blame Makefile, pokud mě zajímá, kdo tam změnil konkrétní řádek).

Dokumentace není jen ve zdrojáku. Zdroják popisuje API, ale těžko bude popisovat třeba to, jak se daná aplikace instaluje a debuguje, s jakými formáty souborů pracuje či jak jsou zdrojáky organizované.

[Michal Kubeček]

Takže radši budete mít v gitu polovinu commitů, které nejspíš nepůjdou ani přeložit, natož aby fungovaly? Happy bisecting… Nemluvě o tom, že ani samotné tvrzení, že se bude hůř psát commit message, mi nedává moc smyslu.

Promiňte mi mou upřímnost (a přímost), ale celá druhá část této diskuse na mne působí, jako kdybyste nikdy s žádným netriviálním projektem do kontaktu nepřišel, ale nejsa nezatížen praktickými zkušenostmi, vytyčil jste jakési teoretické zásady a teď na nich lpíte, přestože lidé, kteří praktické zkušenosti mají, se vám snaží vysvětlit, že nejsou moc v souladu s tím, jak takový vývoj v praxi funguje.