Quando dovresti diramarti?

Quando lavori con un sistema SCM, quando dovresti diramarti?

Ci sono molti usi per la ramificazione. Uno degli usi più comuni è la separazione dei progetti che un tempo avevano una base di codice comune. Questo è molto utile per sperimentare il tuo codice, senza intaccare il tronco principale.

In generale, vedresti due tipi di rami:

  • Feature Branch: se una particolare caratteristica è abbastanza dirompente da non voler influenzare l’intero team di sviluppo nelle sue fasi iniziali, è ansible creare un ramo su cui eseguire questo lavoro.

  • Correzioni ramo: mentre lo sviluppo continua sul tronco principale, un ramo correzioni può essere creato per contenere le correzioni per l’ultima versione rilasciata del software.

Potresti essere interessato a controllare il seguente articolo, che spiega i principi della ramificazione e quando usarli:

  • Ned Batchelder – Subversion branching quick start

In termini generali, lo scopo principale della ramificazione (una funzione 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) sullo stesso ramo univoco.

Ma quel modello mostra rapidamente il suo limite:

Quando hai uno sforzo di sviluppo (refactoring, evolution, bug-fix, …) e ti rendi conto che non puoi apportare tranquillamente tali modifiche nello stesso ramo rispetto al tuo attuale ramo di sviluppo (perché dovresti interrompere l’API, o introdurre un codice che si romperebbe tutto), quindi è necessario un altro ramo.
(Per isolare quel nuovo codice per quello precedente, anche se i due set di codici si uniranno in seguito)

Quindi questa è la tua risposta proprio qui:
Dovresti diramarti 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, se sei in tanti.
Ma non dovresti creare “un ramo per sviluppatore”:
lo scopo di “isolamento” è fatto per isolare uno sforzo di sviluppo (un compito che può essere tanto generale quanto “sviluppiamo la prossima versione del nostro software” o specifica come “risolviamo il bug 23”),
non isolare una “risorsa” .

(un ramo chiamato “VonC” non significa niente per un altro sviluppatore: cosa succede se “VonC” lascia il progetto? Cosa dovresti fare con esso?
un ramo chiamato “bugfix_212” può essere interpretato nel contesto di un sistema di tracciamento dei bug, per esempio, e ogni sviluppatore può usarlo con almeno qualche idea su cosa dovrebbe fare con esso

Un ramo non è un tag (SVN è un sistema di revisione che tenta di proporre funzionalità di versioning come la ramificazione e il tagging attraverso le directory con copia di file a basso costo: ciò non significa che un tag sia un ramo)

Definire un ramo significa anche definire un stream 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 (agnostico VCS) per unire il stream di lavoro tra diversi tipi di filiali: “” Come evolve il software “(pdf)

Definisce il termine codeline (ramo che registra i passaggi significativi di evoluzione del codice, sia attraverso i tag in determinati punti, sia attraverso l’importante unione al ramo)

Introduce il modello della linea principale (una codeline centrale per registrare le versioni) e descrive vari scopi per la ramificazione:

  • Flussi di sviluppo attivo : una codeline persistente quando avvengono vari sviluppi sequenziali
  • rami delle attività : rami di breve durata per attività più specifiche (la correzione dei bug è classica, ma è anche ansible definire un ramo per uno sforzo di unione che si sa complesso da completare: è ansible unire, eseguire il commit e verificare in tale ramo attività senza introdurre problemi per il principale ramo di sviluppo attuale)
  • ramo di staging : per preparare un rilascio, con alcuni dati specifici di pre-produzione o file di configurazione.
  • Filiali private, rami ad hoc e rami sparsi : per attività molto piccole, solo per essere in grado di impegnare alcuni lavori in corso senza attendere il completamento formale o la verifica del test.
    Ciò consente di “impegnarsi presto, impegnarsi spesso”.

Altri concetti interessanti su VCS: concetti di base
(su ClearCase in origine, ma valido anche per qualsiasi VCS)

Tutte le SCM del 21 ° secolo ti stanno dicendo:

Succursale per ogni attività su cui devi lavorare , indipendentemente dal fatto che si tratti di una nuova funzionalità, di una correzione di bug, di un test o altro. Questo è chiamato ramo argomento e cambia il modo in cui lavori con il tuo SCM.

Ottieni:

  • Migliore isolamento
  • Migliore tracciabilità -> associ le attività ai rami, non ai singoli changeset, che ti rendono libero di impegnarti tutte le volte che vuoi e non impone un limite come “un check-in per attività”.
  • I compiti sono indipendenti (normalmente partendo da una baseline stabile, quindi ti concentri solo sul tuo codice, non sulla risoluzione dei bachi dei tuoi), e puoi scegliere se vuoi integrarli a un certo punto o dopo, ma sono sempre sotto controllo della versione
  • Puoi rivedere il codice facilmente (dal controllo della versione, non precompilare le stronzate) prima di colpire la linea principale

Strumenti che possono farlo:

  • Idiota
  • mutevole
  • SCM di plastica

Strumenti che NON POSSONO FARLO:

  • SVN
  • CVS
  • VSS
  • TFS
  • necessariamente

Dipende anche dallo strumento SCM che stai utilizzando. I moderni SCM (git, mercurial, ecc.) Rendono sempre più facile creare e distruggere rami quando necessario. Ciò ti consente, ad esempio, di creare un ramo per bug su cui stai lavorando. Una volta che si uniscono i risultati nel bagagliaio, si scarta il ramo.

Altri SCM, ad esempio sovversione 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-qualcosa-linea. In questo caso, le diramazioni vengono classicamente utilizzate per tracciare intere tracce di sviluppo, come una versione di prodotto precedente o futura.

Quando è necessario apportare modifiche significative e / o sperimentali alla base di codice, in particolare se si desidera eseguire commit delle modifiche intermedie, senza influire sul trunk.

Dipende dal tipo di SCM che stai utilizzando.

Nelle versioni distribuite più recenti (come git e mercurial), stai creando filiali in ogni momento e rimuovendo comunque. Lavorerò spesso su un ramo separato per un po ‘solo perché qualcuno ha rotto la build sulla linea principale, o perché la rete è inattivo, e quindi le modifiche si ripristinano più tardi quando viene riparata, ed è così facile farlo che non è nemmeno fastidioso .

Il documento (breve e leggibile) che mi ha aiutato di più a capire cosa stava succedendo nei sistemi distribuiti è: UnderstandingMercurial .

Nei vecchi sistemi 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 esperimento importante “.

Il modello distribuito è molto meglio, credo, e manca solo di buoni strumenti grafici per diventare il paradigma dominante. Tuttavia non è così ampiamente compreso, e i concetti sono diversi, quindi può essere fonte di confusione per i nuovi utenti.

Trovo che il consiglio di Laura Wingerd e Christopher Seiwald di Perforce sia davvero conciso e utile:

* Branch only when necessary. * Don't copy when you mean to branch. * Branch on incompatible policy. * Branch late. * Branch, instead of freeze. 

Vedi http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf per una spiegazione dettagliata di ciascuna di esse e delle altre migliori pratiche.

Ci sono vari scopi per la ramificazione:

  1. Branche feature / bug. Rami dinamici e attivi che vengono spostati nuovamente nel bagagliaio quando la funzionalità / bugfix è completa.
  2. Rami statici (tag in Subversion, sebbene in sostanza solo un “ramo normale”). Forniscono un’istantanea statica di dire, una versione. Anche se potrebbero essere lavorati, rimangono intatti.

Può anche presentarsi la necessità di ramificazioni:

  • quando vuoi fornire un hotfix a un determinato cliente (ad esempio importante) e non sei sicuro se la correzione farà parte delle versioni future
  • 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 in realtà non invita molta sperimentazione, per non parlare del fatto che le fusioni si fanno davvero male.

    OTOH, non ci sono differenze tecniche tra un ramo e un checkout in SCM distribuiti, e le fusioni sono molto più semplici. Avrai voglia di ramificarti molto più spesso.

    Quando è necessario apportare modifiche, in base al ramo corrente, non destinate alla prossima versione da quel ramo (e non prima).

    Ad esempio, lavoriamo sul tronco di solito. Intorno al momento del rilascio, qualcuno avrà bisogno di apportare una modifica che non vogliamo nella versione attuale (potrebbe essere prima della versione, al momento è di solito dopo la versione). Questo è il momento in cui ci ramifichiamo, per mettere la release sul proprio ramo e continuare lo sviluppo per la prossima release sul trunk.

    Lasciando da parte tutti i tecnicismi …..

    Ramo quando sai che è più facile fondersi!

    Tenendo presente che la fusione sarà sempre effettuata con il modo in cui il lavoro viene svolto in un progetto.

    Una volta raggiunto questo objective, entreranno in gioco tutte le altre questioni terziarie.