Aggiornamento 2019:
In questi giorni, la domanda verrebbe vista in un contesto usando Git e 10 anni di utilizzo di quel flusso di lavoro di sviluppo distribuito (collaborando principalmente tramite GitHub ) mostrano le migliori pratiche generali:
masterè il ramo pronto per essere distribuito in produzione in qualsiasi momento: la versione successiva, con un insieme selezionato di rami di caratteristiche uniti master.dev(o ramo di integrazione, o ' next') è quello in cui vengono testati insieme il ramo di funzionalità selezionato per la versione successivamaintenance(o hot-fix) branch è quello per l'evoluzione della versione corrente / correzioni di bug, con possibili fusioni indietro a deve omaster
Questo tipo di flusso di lavoro (in cui non si unisce deva master, ma dove si uniscono unico ramo funzione per dev, poi, se selezionato, per master, al fine di essere in grado di cadere facilmente caratterizzare rami non è pronto per la prossima release) è implementato nel Git repo stesso, con gitworkflow (una parola, illustrata qui ).
Vedi di più su rocketraman/gitworkflow. La storia di questo sviluppo vs Trunk-Based-Development è annotata nei commenti e nelle discussioni di questo articolo di Adam Dymitruk .
(fonte: Gitworkflow: A Primer orientato alle attività )
Nota: in quel flusso di lavoro distribuito, è possibile eseguire il commit ogni volta che si desidera e inviare senza problemi a un ramo personale un WIP (Work In Progress): sarà possibile riorganizzare (git rebase) i propri commit prima di farli parte di un ramo di funzionalità.
Risposta originale (ottobre 2008, 10+ anni fa)
Tutto dipende dalla natura sequenziale della gestione delle versioni
Innanzitutto, tutto nel tuo baule è davvero per la prossima versione ? Potresti scoprire che alcune delle funzioni attualmente sviluppate sono:
- troppo complicato e deve ancora essere raffinato
- non pronto in tempo
- interessante ma non per questa prossima versione
In questo caso, trunk dovrebbe contenere qualsiasi sforzo di sviluppo corrente, ma un ramo di rilascio definito prima della prossima versione può fungere da ramo di consolidamento in cui solo il codice appropriato (convalidato per la versione successiva) viene unito, quindi corretto durante la fase di omologazione, e infine congelato mentre entra in produzione.
Quando si tratta di codice di produzione, è necessario anche gestire i rami delle patch , tenendo presente che:
- il primo set di patch potrebbe effettivamente iniziare prima del primo rilascio in produzione (il che significa che sai che entrerai in produzione con alcuni bug che non puoi correggere in tempo, ma puoi iniziare a lavorare per quei bug in un ramo separato)
- le altre filiali di patch avranno il lusso di partire da un'etichetta di produzione ben definita
Quando si tratta di dev branch, puoi avere un trunk, a meno che tu non abbia altri sforzi di sviluppo che devi compiere in parallelo come:
- refactoring massiccio
- test di una nuova libreria tecnica che potrebbe cambiare il modo in cui chiamate le cose in altre classi
- inizio di un nuovo ciclo di rilascio in cui è necessario incorporare importanti modifiche architettoniche.
Ora, se il tuo ciclo di rilascio dello sviluppo è molto sequenziale, puoi semplicemente andare come suggeriscono le altre risposte: un trunk e diversi rami di rilascio. Funziona con progetti di piccole dimensioni in cui tutto lo sviluppo entrerà sicuramente nella prossima versione e può essere semplicemente congelato e fungere da punto di partenza per il ramo di rilascio, dove possono essere applicate le patch. Questo è il processo nominale, ma non appena avrai un progetto più complesso ... non sarà più sufficiente.
Per rispondere al commento di Ville M.:
- tieni presente che il ramo di sviluppo non significa "un ramo per sviluppatore" (che innescherebbe "unire follia", in quanto ogni sviluppatore dovrebbe unire il lavoro di un altro per vedere / ottenere il proprio lavoro), ma un ramo di sviluppo per sviluppo sforzo.
- Quando tali sforzi devono essere ricondotti nel trunk (o in qualsiasi altro ramo "principale" o di rilascio definito), questo è il lavoro dello sviluppatore, non - ripeto, NON - il Manager SC (che non saprebbe come risolvere qualsiasi unione in conflitto). Il responsabile del progetto può supervisionare l'unione, ovvero assicurarsi che inizi / termini in tempo.
- chiunque tu scelga per fare effettivamente l'unione, il più importante è:
- disporre di unit test e / o ambienti di assemblaggio in cui è possibile distribuire / testare il risultato dell'unione.
- avere definito un tag prima dell'inizio della fusione per poter tornare allo stato precedente se detta fusione si rivela troppo complessa o piuttosto lunga da risolvere.
