<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Ciao lista, ho scritto questo messaggio su django italia su telegram, ma ho pensato che la mailing list sia anche un buon spunto per poterne discutere.</div><br></div><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Seguendo il gitflow[1] mi ritrovo a lavorare prendendo da `develop` (QA) l'ultimo codice, lavorare nel mio branch e poi rilasciare su `develop` per far si che possa essere testato sull'env di QA.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Tutto bene, tutto ok a parte un problema.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Seguendo lo scrum, alla fine dello sprint, il product owner dovrebbe fare decidere cosa e' pronto per andare in release e cosa non lo e'. Qui sta il problema. Non sempre tutte le feature che sono state lavorare durante lo sprint sono promosse per la release, succede a volte che qualcosa deve essere cambiato e viene rimandato allo sprint successivo.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Se ad esempio abbiamo feature1, feature2, feature3, feature4 che sono state sviluppate partendo dal branch develop, a meno che non si fa il merge di develop in release con tutte le feature[1-4] allora puo' diventare impegnativo fare un release selezionata.</div></div><div dir="ltr"><br></div><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">La prima cosa che mi viene in mente e' di sviluppare le feature partendo i propri branch da release invece che da develop e ovviamente rendendo le feature completamente indipendenti. Questo significa che le varie feature* possono essere applicate senza ripercussioni sia su develop che su release senza rompere i branch.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Il problema potrebbe essere se feature2, ad esempio dipende da feature1, ma in quel caso  feature2 sarebbe un branch del branch di feature1.</div><br></div><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Voi come fate?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><div dir="ltr"><br></div><div dir="ltr"><span class="gmail_default" style="font-family:verdana,sans-serif">[1] </span><a href="https://nvie.com/posts/a-successful-git-branching-model/">https://nvie.com/posts/a-successful-git-branching-model/</a></div><div dir="ltr">-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Karim N. Gorjux<br></div></div></div></div>