Risposte:
Ci sono diversi usi per la ramificazione. Uno degli usi più comuni è per separare i progetti che una volta avevano una base di codice comune. Questo è molto utile per sperimentare con il tuo codice, senza influenzare il tronco principale.
In generale, vedresti due tipi di rami:
Feature Branch: se una particolare funzionalità è abbastanza dirompente da non voler influire sull'intero team di sviluppo nelle fasi iniziali, è possibile creare un ramo su cui svolgere questo lavoro.
Ramo correzioni: mentre lo sviluppo continua sul trunk principale, è possibile creare un ramo correzioni per mantenere le correzioni all'ultima versione rilasciata del software.
Potresti essere interessato a controllare il seguente articolo, che spiega i principi della ramificazione e quando usarli:
In termini generali, lo scopo principale del branching (una funzionalità VCS - Version Control System) è ottenere l' isolamento del codice .
Hai almeno un ramo, che può essere sufficiente per lo sviluppo sequenziale, e viene utilizzato per molte attività registrate (impegnate) su quello stesso ramo univoco.
Ma quel modello mostra rapidamente il suo limite:
Quando hai uno sforzo di sviluppo (refactoring, evoluzione, correzioni di bug, ...) e ti rendi conto che non puoi apportare in sicurezza tali modifiche nello stesso ramo del tuo attuale ramo di sviluppo (perché interromperesti l'API o introdurrebbe codice che non funzionerebbe tutto), quindi hai bisogno di un altro ramo.
(Per isolare nuovo codice per quello legacy, anche se i due set di codici verranno uniti in seguito)
Quindi questa è la tua risposta proprio qui:
dovresti ramificare ogni volta che non puoi perseguire e registrare due sforzi di sviluppo in un ramo.
(senza avere una storia orribilmente complicata da mantenere).
Un ramo può essere utile anche se sei l'unico a lavorare sul codice sorgente, o se siete in tanti.
Ma non dovresti creare "un ramo per sviluppatore":
lo scopo di "isolamento" è fatto per isolare uno sforzo di sviluppo (un'attività che può essere generale come "sviluppiamo la prossima versione del nostro software" o specifica come "sistemiamo bug 23 "), per
non isolare una" risorsa " .
(un ramo chiamato "VonC" non significa nulla per un altro sviluppatore: cosa succede se "VonC" lascia il progetto? Cosa dovresti farci?
Un ramo chiamato "bugfix_212" può essere interpretato nel contesto di un sistema di tracciamento dei bug, ad esempio e qualsiasi sviluppatore può usarlo con almeno un'idea di cosa dovrebbe farci)
Un ramo non è un tag (SVN è un sistema di revisione che cerca di proporre funzionalità di versioning come il branching e il tagging di directory con una copia di file economica: ciò non significa che un tag sia un branch)
Definire un ramo significa anche definire un flusso di lavoro di unione : devi sapere dove unire il tuo ramo quando hai finito.
Per questo, il capitolo 7 di Practical Perforce (Laura WINGERD - O'Reilly) è una buona introduzione (VCS agnostico) per unire il flusso di lavoro tra diversi tipi di rami: "" How Software Evolves "(pdf)
Definisce il termine codeline (ramo che registra fasi evolutive significative del codice, sia tramite tag in determinati punti, sia tramite importanti merge al ramo)
Introduce il modello della linea principale (una codeline centrale per registrare i rilasci) e descrive vari scopi per la ramificazione:
Altri concetti interessanti su VCS: Concetti di base
(su ClearCase originariamente, ma validi anche per qualsiasi VCS)
Tutti gli SCM del 21 ° secolo ti stanno dicendo:
Ramo per ogni attività su cui devi lavorare , non importa se si tratta di una nuova funzionalità, una correzione di bug, un test, qualunque cosa. Questo è chiamato topic branch e cambia il modo in cui lavori con il tuo SCM.
Ottieni:
Strumenti che possono farlo:
Strumenti che NON POSSONO farlo:
Dipende anche dallo strumento SCM che stai utilizzando. I moderni SCM (git, mercurial, ecc.) Rendono sempre più facile creare e distruggere i rami quando necessario. Ciò ti consente, ad esempio, di creare un ramo per bug su cui stai lavorando. Una volta uniti i risultati nel tronco, scarti il ramo.
Altri SCM, ad esempio subversion e CVS, hanno un paradigma di ramificazione molto più "pesante". Ciò significa che un ramo è considerato appropriato solo per qualcosa di più grande di una patch di venti righe. Lì, i rami vengono utilizzati in modo classico per tenere traccia di interi percorsi di sviluppo, come una versione del prodotto precedente o futura.
Quando è necessario apportare modifiche significative e / o sperimentali alla base di codice, in particolare se si desidera eseguire il commit di modifiche intermedie, senza influire sul trunk.
Dipende dal tipo di SCM che stai utilizzando.
Nelle versioni distribuite più recenti (come git e mercurial), crei rami tutto il tempo e riemergi comunque. Spesso lavorerò su un ramo separato per un po 'solo perché qualcuno ha rotto la build sulla linea principale, o perché la rete è inattiva, quindi unisco le modifiche in un secondo momento quando viene risolto, ed è così facile da fare che non è nemmeno fastidioso .
Il documento (breve e leggibile) che più mi ha aiutato a capire cosa stava succedendo nei sistemi distribuiti è: UnderstandingMercurial .
Nei sistemi più vecchi con un repository centrale, (come CVS, SVN e ClearCase), si tratta di un problema molto più serio che deve essere deciso a livello di team e la risposta dovrebbe essere più simile a "mantenere una vecchia versione pur consentendo sviluppo per continuare sulla linea principale ", o" come parte di un grande esperimento ".
Il modello distribuito è molto migliore, credo, e manca solo di strumenti grafici carini per diventare il paradigma dominante. Tuttavia, non è così ampiamente compreso ei concetti sono diversi, quindi può creare confusione per i nuovi utenti.
Trovo che i consigli di Laura Wingerd e Christopher Seiwald di Perforce siano davvero concisi e utili:
* Branch only when necessary.
* Don't copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.
Vedere http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf per una spiegazione dettagliata di ciascuno di essi e per altre best practice.
Ci sono vari scopi per la ramificazione:
Ogni volta che ne hai voglia.
Probabilmente non lo farai molto spesso se lavori con un SCM centralizzato poiché i rami fanno parte del repository ufficiale, e questo non invita davvero a fare molta sperimentazione, per non parlare del fatto che le fusioni fanno davvero male.
OTOH, non c'è differenza tecnica tra una filiale e un checkout negli SCM distribuiti e le unioni sono molto più semplici. Avrai voglia di ramificarti molto più spesso.
Quando hai bisogno di apportare modifiche, in base al tuo ramo attuale, non destinato alla prossima release da quel ramo (e non prima).
Ad esempio, di solito lavoriamo sul tronco. Intorno al momento del rilascio, qualcuno avrà bisogno di apportare una modifica che non vogliamo nella versione corrente (potrebbe essere prima del rilascio, al momento di solito è dopo il rilascio). Questo è il momento in cui eseguiamo il branch, per mettere il rilascio sul proprio ramo e continuare lo sviluppo per il prossimo rilascio su trunk.
Lasciando da parte tutti i tecnicismi .....
Ramo quando sai che è più facile unire di nuovo!
Tenendo presente che la fusione sarà sempre effettuata con il modo in cui il lavoro viene svolto in un progetto.
Una volta raggiunto questo obiettivo, entreranno in gioco tutte le altre questioni terziarie.