Quando dovrebbero essere creati i rami di sviluppo?

Non mi piacciono i rami arbitrari, cioè le correzioni di Fred o le correzioni di Harry. Sono molto più a mio agio con una (indipendente) funzione di una branca che consente a più sviluppatori di operare su una funzione; ma per la feature da unire solo quando è completa.

Quindi, in questo momento hai solo bisogno del ramo "bugfix" ma una volta avviato lo sviluppo dovresti creare un ramo per ogni caratteristica significativa. In questo modo quando hanno finito possono essere uniti in & rilasciato senza dipendere da altre funzionalità di buggier.

Non sei sicuro di quanto TFS sia valido per la fusione, ma sono sicuro che lo saprai tra qualche mese:)

We can't get by with a single development branch because we will want to merge to Main while other work is completed.

Sembra che tu sappia che devono essere creati più rami di sviluppo. Mi vengono in mente due possibili scenari:

1. Ciascuno dei cinque sviluppatori sta lavorando su parti indipendenti del progetto (bug-fixing) - Assicurati che una singola filiale sia creata per ogni sviluppatore. Questo pone l'onere e la responsabilità su ogni sviluppatore per assicurarsi che il loro insieme di modifiche non sia in conflitto con il lavoro di qualcun altro. È molto probabile che uno dei tuoi cinque sviluppatori commetta un errore. Se / Quando questo è il caso, non ha senso che tutti gli altri vengano bloccati.
2. Sviluppi di funzionalità multiple - Indipendentemente dal numero di sviluppatori che lavorano su una particolare funzione / bug, questi dovrebbero essere separati. Un esempio di questo è benefico è che tutti i commit di codice fanno parte delle caratteristiche che si stanno sviluppando - non ci sono secondi indovinelli coinvolti.

Filiali di lavoro implicite con DVCS

Usiamo Mercurial quindi c'è il ramo di lavoro implicito nella scatola degli sviluppatori. I commit vengono sempre eseguiti nello spazio di lavoro locale. Quando una parte di lavoro rilasciabile viene completata, viene trasferita al server di repository primario dove viene automaticamente costruita e testata.

Non creiamo quasi mai rami espliciti, ma di nuovo i nostri sprint non durano più di 1 settimana e le carte non durano più di 1-2 giorni.

Inoltre, puoi mitigare l'unificazione del dolore inserendo il lavoro da altre parti del codice o da altri progetti in modo che le persone non debbano fare fusioni difficili tutte le volte.

Ho usato sia single branch per story sia un ramo per release (tutti gli sviluppatori eseguono il check-in delle loro storie da svalutare e se qualcuno di loro interrompe il branch dev è rotto per tutti). Consiglio vivamente l'unico ramo per storia se non ti piacciono i conflitti. Il ramo dev rimarrà sempre stabile per tutti gli sviluppatori e non ci sarà tempo di attesa per uno sviluppatore che lavora su un pezzo di codice che un altro sviluppatore ha già rotto. Quando la tua storia è finita, tutto il tuo codice è nella tua filiale. Lo unirai a dev ma non effettuerai il check-in e il test, in caso di conflitti lo risolverai e chiederai alla persona con cui sei in conflitto per evitare di rimuovere il suo codice. Quindi unire a dev. Questo aiuta tutti gli sviluppatori a funzionare senza intoppi. Dipende anche dalle dimensioni dell'azienda. La nostra azienda ha 200 sviluppatori che lavorano contemporaneamente su una base di codice, ma una filiale separata per le loro storie. Una volta che il codice è unito al ramo dev, il ramo della storia viene immediatamente cancellato. Spero che questo possa essere d'aiuto. Grazie

Se questo è basato su git, devi solo creare un ramo per ogni correzione di bug, correggere il bug nel più breve tempo possibile, unire il ramo di correzione del bug con il ramo di sviluppo, quindi spingere la modifica al ramo di sviluppo. La revisione delle richieste di pull e l'unione dovrebbero essere la priorità più alta , poiché più rapidamente si ottiene, maggiori sono le possibilità che l'unione non causi problemi. Una volta uniti, questi rami possono essere cancellati.