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.
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...
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. :)
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.
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ší. :)