Ogni ramo ha il suo ruolo - il suo scopo. La sua intera ragione di essere. Una volta che lo scopo è completo, il ramo dovrebbe essere chiuso per ulteriori modifiche e reinserito nella linea principale.
Avere un ramo di rilascio perpetuo significa che lo scopo del ramo non è mai completo, in quanto è perennemente aperto alle modifiche. Ogni volta che hai una nuova versione, ti ritrovi a fondersi dal ramo di sviluppo nel ramo di rilascio. E questa non è una fusione di idee - è una sostituzione completa dello stato del ramo di rilascio con l'attuale capo degli sforzi di sviluppo. Quando non è una sostituzione completa dello stato del codice dallo sviluppo (che è in teoria, pronto per il rilascio), fornisce un punto in cui i bug da insinuarsi differiscono tra il ramo di rilascio e il ramo di sviluppo.
La completa sostituzione dello stato piuttosto che un'unione è un indizio distinto che il vecchio ramo è fatto e questo è uno nuovo. Per renderlo chiaro a tutti, ecco un altro ramo di rilascio.
Considera anche la situazione (non improbabile) in cui ci sono due versioni in corso allo stesso tempo . Lo sforzo di rilascio richiede due mesi (certificazione, test, più test, correzione dei bug che compaiono nello sforzo di rilascio, ricertificazione, packaging per le diverse build). E ora, un mese dopo, viene avviato lo sforzo di un altro per la versione successiva . Questo è uno scopo diverso: un ramo diverso.
Oppure considera la situazione in cui hai un ramo di rilascio, che poi diramai per ogni piattaforma che stai per distribuire (apportando le modifiche necessarie per farlo funzionare bene sui sistemi Mac, Windows e Unix). E anche se la versione 1.0 potrebbe essere la porta per Windows, gli sforzi per Mac e Linux richiederanno un altro pezzo di tempo (mentre state leggendo la versione 1.1). Di nuovo, ognuno di questi è una versione separata e un ramo separato.
Uno dei miei whitepaper preferiti sulla ramificazione è quello delle Strategie di ramificazione avanzata di SCM . Mentre questo ha un focus su perforce (un sistema di controllo della versione centralizzato al momento). I concetti che propone possono essere chiaramente mappati nel modello git-flow.
In questo whitepaper, il ruolo di packaging è quello che si associa al ramo di rilascio di git-flow.
The packaging role is often confused with the accumulation or, more commonly, mainline roles. Once the intended development and maintenance have been performed and any accumulation has been done, it is time to prepare the code for release. Such an effort may not be trivial, requiring a team of release engineers and additional fixes beyond those already performed. The policy on a packaging branch is significantly different from that on a maintenance branch, as the packaging role suggests, only the changes necessary to make the product releasable should be addressed.
If work is to proceed on the other product branches, as is likely to happen if patch levels of the product are to be produced, one does not want the release effort to stall progress toward the next patch level. Other packaging branching strategies could even keep minor versions running off of the same mainline, compounding the potential for a stall while the packaging activity takes place.
Using a separate branch to insulate the release effort from the ongoing development and maintenance, and vice versa, is recommended. In a multi-platform environment, it may be advisable to create one packaging branch per platform for the final porting effort. If the porting efforts are staggered, this allows the staggered releases to be reflected in the version hierarchy. If the porting efforts are simultaneous, accumulating the per-platform packagings to a master packaging branch, from which the final build would be performed, should also be considered. This should be determined in advance, as creating the separate packaging branches from the master packaging branch works best.
Questo è il motivo per cui si separa il ramo di rilascio dal ramo principale, e anche perché si separano i rami di rilascio l'uno dall'altro.