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.