Abbiamo bisogno di un ramo separato per correggere i bug generati durante la fase di test?

Se ti ho capito bene, hai il seguente problema:

• prima che venga distribuita la nuova versione, il tuo ramo di rilascio è attualmente l'unico che raccoglie tutte le correzioni. Uno sviluppatore che desidera aggiungere una nuova correzione (in particolare una correzione a un problema causato da una correzione precedente), non può testarlo in modo affidabile in un ramo di sviluppo, perché, in quel momento, le correzioni apportate prima di non sono integrati nelle linee di sviluppo .
• così attualmente l'unico modo per il tuo team di risolvere questi problemi è quello di controllare il ramo di rilascio corrente, aggiungere la nuova correzione lì, testarla localmente e poi eseguirla sul ramo di rilascio. Naturalmente, questo dovrebbe essere correttamente comunicato al tuo team di QA, ma anche in questo caso potrebbe esserci il rischio di interferire con l'attuale attività di controllo qualità.

L'introduzione di un ulteriore ramo di bugfix ti consentirà di rinviare l'immediata consegna delle correzioni al team addetto al QA. Questo ha pro e contro. Dal lato pro,

• consente ai tuoi sviluppatori di testare le correzioni integrate non solo localmente prima passano al QA
• consente al tuo team di unire le correzioni in "release" e consegnarle al QA in un momento più preciso, il che potrebbe ridurre la percezione della tua app web come un "bersaglio mobile". Potresti raccogliere alcune correzioni e il team addetto al QA ottiene ogni due giorni un nuovo "pacchetto" di correzioni, in grado di testarlo.

Sul lato con,

• devi gestire questo ramo aggiuntivo e quando le modifiche vanno in "rilascio", che significa ulteriori passaggi di unione
• il team addetto al QA non riceve immediatamente le correzioni al termine.

Si noti, tuttavia, anche quando non si utilizza un ramo "bugfix", il team addetto al controllo qualità non necessariamente ottiene immediatamente le correzioni push nella propria copia locale. Se vogliono ogni due giorni un nuovo "pacchetto" di correzioni, aspettano solo due giorni prima di aggiornare la loro copia locale di "rilascio" per ottenere le correzioni. La differenza è: con un ramo di bugfix, puoi tenerlo sotto il controllo migliore degli sviluppatori, con un solo ramo di rilascio, il controllo è probabilmente più sul lato QA.

Confronta quei pro e contro e decidi tu stesso quale di questi due approcci funzionerà meglio per la tua squadra.

Gitflow suggerisce di impegnarsi direttamente nel ramo di rilascio

only bug fixes, documentation generation, and other release-oriented tasks should go in this [the release] branch

Tuttavia, se ci sono più sviluppatori che lavorano su un ramo di rilascio, ha senso che facciano "rilasciare feature branch"

Se ti trovi in questa posizione, però, dove lavori molto sui rami di rilascio, forse dovresti chiederti se il ramo di sviluppo era finito in primo luogo. Nella maggior parte dei posti in cui ho lavorato, abbiamo fatto QA sul ramo dev, PRIMA di creare una versione o passare al prossimo set di funzionalità.

Esistono due tipi di rami, rami condivisi e rami propri. In questo caso, il ramo di rilascio è un ramo condiviso fino al rilascio. È importante mantenere pulito lo stato delle filiali condivise dal numero di persone che dipende da esso. Inoltre, la creazione di un nuovo ramo offre la flessibilità necessaria per svilupparsi, testare e rilasciare in modo indipendente. Anche tu puoi decidere di buttar via e ricominciare da capo.

Nel caso menzionato sopra, correggi i bug, testalo e unisci per rilasciare il ramo una volta che è pronto. Spero che questo aiuti.

Link: link

- Aggiornamento -

Dipende dalla tua strategia di test per aggiungere in modo incrementale correzioni al ramo di rilascio o aggiungere tutto sotto un ramo e rilasciarlo. Un singolo grande ramo potrebbe essere più difficile da gestire in quanto git non è molto amichevole nell'invertire i commit e le modifiche. Git non viene fornito con alcuna strategia di ramificazione o flussi di lavoro. Sta a noi scegliere cosa funziona per noi e molte grandi aziende hanno pubblicato alcuni flussi di lavoro. Nella maggior parte dei casi, preferisco lavorare con il flusso di lavoro git-flow o GitHub.