Deci, așa cum am zis, fiecare task depinde de anteriorul.
Eu m-am gândit la două-trei abordări:
Toate task-urile sunt într-un singur branch. Cel mai la îndemână dar și cel mai păcătos dacă ai nevoie de bisect
spațiezi task-urile în așa fel încât să ai merge în master pentru fiecare branch. Doar că asta nu este tot timpul posibil (e.g. task-urile trebuiesc terminate asap și nu poți aștepta acel merge)
faci stacked pull request (branch din branch din branch), dar trebuie să ai grijă să nu se facă merge în ordinea greșită și să ții branch-urile în sync
Eu prefer primele două variante și am evitat-o pe cea de-a treia.
eu cand am avut de-a face cu asa ceva am mers pe un singur branch.
inceput cu branch de epic, plecat cu un branch pt fiecare task si merguit in epic cand era gata, plecat cu urmatorul
Eu consider master-ul de pe local ca fiind acel “feature branch”. Din moment ce fiecare task depinde de cel anterior, nu are sens sa ai mai mult de master-ul local (un singur feature branch). Mai mult, e folositor sa ai commit-urile originale (cu mici schimbari) decat un singur merge commit cu tot feature-ul deodata (e mai greu de gasit probleme asa)
Am incercat mai multe moduri de lucru: master, master/develop, master/develop/feature-branches etc. Am ajuns la concluzia ca depinde de proiect si, pentru mine, cea mai buna solutie e a folosi doar master (pe local si remote) si sa creezi feature branch-uri doar cand chiar ai nevoie (mai intai pe local si eventual pe remote)
Nu cred că există o variantă universal valabilă.
Eu personal tind să mă feresc de folosirea în exces a branch-urilor.
Revenind la contextul general al întrebării din topic cred că pot fi relevante alte informații despre proiect. De exemplu cred că este important și numărul de oameni din echipă. Un număr mai mare de membri va complica repede gestiunea generală a proiectului și operațiile de merge sau bisect.
La modul general cred că modul în care natura proiectului permite testarea și verificarea are de asemenea are o influență majoră.
in majoritatea cazurilor si masterul si developul o sa fie protejate. aka, nu poti sa faci push in ele. ce spuneti voi acolo are sens doar daca lucrati singuri. si nici atunci nu-i corect, doar daca folosesti vcs-ul ca backup.
Lucrez fara probleme in modul asta cu echipe de 4-5 doar cu master sau master/develop de multi ani. Nu vad vreo problema cu modul acesta de lucru… Folosesti tag-uri pentru fiecare deploy eventual, sa stii unde e fiecare versiune. Rareori e necesar un branch pe remote (doar la ceva refactorizare mare, schimbare de framework etc.)
“Protejarea” o poti dezactiva oricand. Nu conteaza ce-i “corect” ci ce ii mai eficient, rapid si functioneaza destul de bine.
Sigur, in proiecte open source treaba sta putin mai diferit. Aici ma refer la proiectele private si echipe relativ normale (1-8 devs)
Nu inteleg unde are loc etapa de Code Review in tot acest proces/workflow pe care il prezinti tu.
Nu poti face Code Review da ca nu folosesti branch-uri pe remote si PR-uri.
Ca sa revin la intrebarea initiala a topic-ului.
Un branch separat are sens sa existe atat timp cat el poate fi merge-uit, individual, in integration branch (fie el master, featN sau featN.1; nivelul nu conteaza).
Altfel, daca acest branch contine doar franturi de implementare, iar la un merge neordonat (apropo de ordinea in care faci merge la PR-uri) in integration branch, ar crapa codul, practic nu-si are sensul acest branch, in cauza.
Atata timp cat un PR sau branch e un working version, un independent deliverable, poti sa faci orice combinatii de PR-uri/merge-uri: ori toate catre master, ori catre epic branch / ori stacked pull request (punctul 3 din exemplul tau) - n-ai cum s-o dai in bara.
Singura diferenta va fi ca ori integrezi mai multe schimbari deodata, ori le integrezi pe rand…
Personal, rar spre nicidoata am avut nevoie sa ma duc pe mai mult decat 2 nivele (nivelul 0 fiind master)
Face to face sau intr-un video call inainte de a da push. Dar, de obicei, code review nu e necesar daca ai programatori capabili in echipa si feature-urile nu afecteaza alte parti din cod. Din nou, depinde de proiect si echipa