Přidat otázku mezi oblíbenéZasílat nové odpovědi e-mailem Git - zobrazení všech změn ještě před mergem

Ahoj,

V týmu vyvíjíme v PhpStormu a máme všichni projekt synchronizovaný se vzdáleným gitem.
Jeden kolega udělá nějaké změny a nahraje do remote 4 commity. Já si udělám fetch, * a pak merge. Jde nějak těsně před dokončením merge nechat si zobrazit všechny soubory se změnami a nejlépe pak nějakou změnu zamítnout tím, že si nechám svůj řádek kódu?

Kolikrát někdo udělá takové nešikovné změny a já se pak musím koukat do logu a vytahovat si zpět můj původní kód (kolikrát třeba jen jeden řádek), protože žádný konflikt nevznikne, prostě se jen udělá automatický merge a já se o té změně nemám šanci dozvědět, když se sám nepodívám.

* Pokud chci zobrazit všechny změny, tak to zatím obcházím tak, že po fetchi si zkopíruju celý adresář s projektem, udělám merge a hned si můžu porovnat soubory před a po.

Na internetu jsem něco našel, co by právě mělo dělat, na co se tady ptám, a to, že v možnostech při mergi se má vybrat metoda merge resolve - to ale nefunguje podle představ.

U konfliktů se mi klasicky zobrazí, že je musím vyřešit já, ale neexistuje opravdu nějaká možnost dělat v PhpStormu merge tak, jak jsem popsal?
PhpStorm umí úžasné věci, a já jsem zatím v začátcích, takže ještě nevím, co všechno v něm jde. Budu rád i za rady nebo tipy, jestli to jde líp, než jak to aktuálně obcházím já.

Díky.

Jsou zobrazeny jen nové odpovědi. Zobrazit všechny
Předmět Autor Datum
Ahoj, napadl mě takový model, že budou tyto větve: dev-developer1 (local) - vlastní větev, kde si m… nový
Phpp 05.04.2020 00:30
Phpp
Ja mám teraz vetvy: master, dev, funkcionalita1, funkcionalita2, func3, func4, vyvojar1, vyvojar2, v… nový
Mlocik97-m 05.04.2020 03:12
Mlocik97-m
Changelog: git log --oneline --decorate nový
MaSo 05.04.2020 12:10
MaSo
Mám na mysli changelog ve formátu Markdown - https://github.com/skywinder/gitlab-changelog-generator… nový
Phpp 05.04.2020 15:40
Phpp
Prešiel som si už viacerými branching stratégiami a za mňa jednoznačné platí, že čím menej vetiev, t… nový
los 06.04.2020 00:00
los
Me se naopak osvedcilo vic vetvi = min noveho kodu ve vetvi = meni problemy s mergovanim. Hlavni vet… nový
Henonee 06.04.2020 04:03
Henonee
Problém vidím hlavne v tom, že čím viac vetiev, tým viacej mergovania. Mergovanie robí často niekto… nový
los 06.04.2020 07:09
los
Myslim, ze mluvime v podstate o tom samem :) Jen vy mate o jednu uroven vic kde vam vic lidi dela na… nový
Henonee 06.04.2020 18:02
Henonee
Ta samostatná větev release měla sloužit, jak už název napovídá, jako mezikrok před releasem z větve… poslední
Phpp 07.04.2020 22:38
Phpp

Ahoj,

napadl mě takový model, že budou tyto větve:
dev-developer1 (local) - vlastní větev, kde si může developer1 vyvíjet
dev-developer2 (local) - vlastní větev, kde si může developer2 vyvíjet
dev (local, remote) - hlavní vývojová větev, kam budou všichni pushovat ze své větve
release (local, remote) - zde se bude dělat code review a opravená verze se pushne do masteru s tagem a zároveň zpět do dev taky s tagem
master (local, remote) - zde budou pouze zkontrolované verze z větve release

Z dev-developer1 se nějakým příkazem zkopčí všechny mé commity na dev, kterou si někdo naclonuje, přepne se na dev-developer2, udělá si pár vlastních commitů a nahraje je všechny taky na dev, já si to na local fetchnu, rebasnu si na dev-developer1 změny atd.
Idea byla taková, že se z té dev větve bude automaticky generovat changelog.

Moje otázky:
1. Je to použitelný model, nebo je to moc složité? Případně máte nějaký svůj lepší model?
2. Existuje příkaz na to "zkopčení" mých commitů na dev? EDIT: Po chvíli mi to došlo - merge. Ach, ta karanténa... :-D
3. Máte nějaké zkušenosti s automatickým generováním changelogu? Jak se to dělá? (Konvenci na pojmenovávání commitů máme vlastní.)

Díky. :)

Ja mám teraz vetvy: master, dev, funkcionalita1, funkcionalita2, func3, func4, vyvojar1, vyvojar2, vyvojar3, vyvojar4, published, _0.x, _1.x, pr, test, to_test, export, build...

a to sme 4 v tyme (reálne funkcionalita je nazov konkretnej funkcionality, a vyvojar konkretne meno/nick) a 18 větví

Prešiel som si už viacerými branching stratégiami a za mňa jednoznačné platí, že čím menej vetiev, tým lepšie. Viac vetiev znamená viac mergovania, viac mergovania znamená viac konfliktov, a viac konfliktov znamená viac príležitostí na to, aby sa niečo pokazilo.

Pár poznámok k stratégii, ktorú si načrtol. Vetvy "kde si môže developer X vyvíjať" nedávajú zmysel. Vývojár predsa nevyvíja len tak niečo pre seba. Podobne nezmyselná mi príde aj vetva release, ktorá podľa popisu ani neslúži na release, ale na code review. A keď sa bude robiť code review po rôznych vývojároch naraz, tak sa budú navzájom blokovať, alebo ako je to myslené?

Takže za mňa, nemajú tam byť vetvy pre vývojára (developer), ale pre funkcionalitu (feature). Na jednej funkcionalite môže súčasne pracovať viacero vývojárov. Code review potom robíme priamo v tejto vetve. Až keď je vetva implementovaná, zrevidovaná (v ideálnom prípade) a otestovaná (v najideálnejšom prípade), tak až vtedy sa merguje do master vetvy. Nad samotnou master vetvou sa nič nevyvíja, všetok vývoj prebieha vo feature vetve.

Kvôli prehľadnej histórii robíme pred mergom vždy rebase feature vetvy na master vetvu, a samotný merge robíme vždy --no-ff (nie fast-forward). Tým pádom vidíme v histórii, ktoré komity prišli s mergovanou funkcionalitou, a zároveň merge commity v master vetve slúžia ako change log. Feature vetvu po merge mažeme.

Rebase samozrejme robíme pri dlhšie trvajúcom vývoji aj priebežne. Snažíme sa ho spraviť aj pred code review a takisto aj pred testom. Všetko preto, aby sme sa vyhli konfliktom pri mergovaní do master vetvy.

V master vetve držíme kód v kvalite production-ready, takže keď sa chce hocikedy releasovať, tak už nie je potrebné nič nikam mergovať. Spraví sa tag a ide sa ďalej.

Me se naopak osvedcilo vic vetvi = min noveho kodu ve vetvi = meni problemy s mergovanim.
Hlavni vetve minimalne Master (v podstate ciste releasy), Devel (kde se schazi hotovy vyvoj a delaji kompletni testy a QA) pak feature vetve a (vetsinou z nich) bug vetve (resici nahlasene ci objevene chyby).
S tim, ze se vyssi vetev nejdriv mergne do aktualni, otestuje se (a pripadne opravi a znovu mergne ta vyssi) a pak se cela aktualni mergne do vyssi se --squash a dukladnym popisem (a nasledne se vetsinou zahodi a vytvori se nova)

Vysledek je, ze commity ve vyssich vetvich jsou ridke a "genialni" - proste kompletne resi dany problem a vypada to, ze se to povedlo napoprve dokonale - nejsou tam commity typu "jdu na obed", "X zacina chodit, ale Y se rozbilo", "Y uz zas chodi, ale X bude potreba strukturovat jinak s ohledem na Z" a podobne (protoze commit delam nejpozdeji kdyz odchazim od pocitace, ale casto i po kazdem uspesnem kroku (17 z 94) treba po 10 minutach) - po tydnu uz nikoho nezajima, jake preklepy jsem udelal rano a vecer opravil, kolikrat jsem prejmenoval promennou ci zmenil poradi deklaraci a podobne, ale ze "chyba #456 opravena" nebo "pridan export pro system XYZ"

Pak taky hledani problemu bisekci probehne rychleji, ale hlavne celkem jednoznacne (je to rozbite od "pridan export pro system XYZ" , nikoli ze chyba se vyskytuje v tomto useku asi tak v kazdem tretim commitu a ve zbyvajicich dvou ne, schvalne kam se trefite pulenim ...)

Problém vidím hlavne v tom, že čím viac vetiev, tým viacej mergovania. Mergovanie robí často niekto iný než samotný vývojár, a v prípade konfliktov by potom musel obiehať jednotlivých ľudí a riešiť ich s nimi. A čím viacej vetiev je medzi samotným commitom a výsledným mergnutým kódom, tým je to horšie. To je réžia navyše, ktorú sa snažíme minimalizovať.

Commity typu "idem si spraviť kávu" do feature repozitára vôbec nepatria, pretože také commity absolútne nikoho nezaujímajú. Taký spôsob práce môže fungovať leda tak vtedy, keď na jednej feature robí maximálne jeden vývojár. Ak má niekto potrebu také commity robiť, tak u seba lokálne si môže robiť čo chce, ale do feature repozitára musí komitovať ucelené zmeny. A toto je aj dôvod, prečo nie som zástanca squashovania (mimo lokálneho repozitára), kedy sa strácajú cenné informácie o tom, prečo sa nejaká zmena v kóde vlastne udiala a kto ju spravil.

S rýchlosťou hľadania problémov pomocou bisectu nie je problém, keďže naozaj nerobíme commity pri každom vstaní od klávesnice. A výsledok je aj u nás vždy jednoznačný, keďže robíme rebase a vďaka tomu máme lineárnu históriu. Nepotrebujeme "geniálne" commity, ich účel plní práve ten jeden merge commit. Čo potrebujeme, je história zmien, aby sme rozumeli tomu, prečo nejaký kód vyzerá práve tak, ako vyzerá.

Myslim, ze mluvime v podstate o tom samem :) Jen vy mate o jednu uroven vic kde vam vic lidi dela na jedne feature naraz a potkavaji se tam - my meli ty featury mensiho rozsahu, nebo se operativne rozbehly do vice mensich vetvi s jemnejsim delenim featur. Ty commity "jdu na kafe" si delali vyvojari lokalne, kazdy pak zodpovidal za commit do hlavni feature vetve (ktery uz byl vycisteny a squashnuty s tim, ze vychazel z te hlavni feature vetve).

Takze na "serveru" uz byly prave ty "ciste" komity typu "bug #123 sjednoceni pouzitych fontu" (zatimco mezikroky "obrazovky a1-a12", "b1-25","jdu na obed", "docisteni a10 pro includy", "a4 nesedi example, ale uz jdu domu - projit jeste ostatni examply","oprava a1-a5 ohledne ukazek starsi verze", "c1-c5", "c6-c17" mel ten vyvojar u sebe a "bug #123.." bylo az to squashnuti do sdilene casti - uz bez preklepu a naslednych oprav a s examply, kde ty fonty byly vlastne textem a tykaly se neceho jineho) - a vysledek byl, ze fonty byly sjednocene na vsech obrazovkach, ale priklady pro jiny produkt mely puvodni fonty.

Protoze celkem casto ty jednoduche komity nebyly tak uplne jasne jak udelat nejlip, bylo treba postupne zkusit nekolik pristupu, vychytat preklepy, clovek na tom delal treba i par dni v kuse (nemluve o tom, ze obcas byl prerusen dulezitou opravou/upravou v prioritnejsi casti a pak se k tomu zase vracel). Takze se ukladalo/komitovalo porad u vyvojaru (i veci, ktere byly "momentalne rozbite") a centralni vetve sdilene mezi nezavislymi vyvojari uz byly "dostatecne stabilni" v kazdem kommitu

Ta samostatná větev release měla sloužit, jak už název napovídá, jako mezikrok před releasem z větve dev a zároveň pokud by bylo potřeba po releasu udělat nějaký rychlý hotfix, tak by se to mohlo udělat na větvi release, kde by se to rovnou releaslo opravené do masteru i do dev.

Každopádně vám, pánové, díky na různé pohledy, popřemýšlím o tom a vyberu si z toho to nejlepší. :)

Zpět do poradny Odpovědět na původní otázku Nahoru