Qual è il modo consigliato per separare lo sviluppo corrente dallo sviluppo della manutenzione nel software di controllo della versione?

10

Ho alcune applicazioni software gestite usando Git. Ho appena rilasciato una nuova versione 2.x che ho intenzione di mantenere a lungo termine (correzioni di bug per lo più). Nel frattempo, vorrei iniziare a lavorare sulla versione 3.x. Qual è il modo consigliato per gestirlo? Devo creare un ramo per la versione 2.x e avere lo sviluppo 3.x sul master? o l'altro modo?

    
posta this.lau_ 23.12.2011 - 10:46
fonte

2 risposte

13

Un modo molto interessante di fare le cose è stato descritto qui: Un modello di branching Git riuscito

L'ho trovato molto intrigante, ma devo ancora usarlo.

Molto bene, come richiesto una (molto) breve sommatoria di ciò che l'articolo dice:

  • Il ramo principale solo rappresenta le pietre miliari finite (ad esempio versione 1.0, 1.1, 1.2 ecc.)
  • Lo sviluppo è fatto nel proprio ramo (convenientemente chiamato "sviluppo", chi avrebbe mai pensato?). Il ramo di sviluppo viene unito nuovamente al ramo Master, ogni volta che viene eseguita una versione completa della funzionalità.
  • I rami staccati dallo sviluppo sono rami di funzionalità. Questi rappresentano singole funzionalità per la prossima (o qualsiasi futura) versione. Si fondono con il ramo di sviluppo.
  • Un altro ramo derivante dallo sviluppo è il ramo "release". Questo è un ramo che rappresenta una versione di rilascio quasi completa in cui solo i dettagli minori devono essere ripuliti. Si fonde con il ramo di sviluppo e in definitiva con il ramo Master
  • "Hotfix" ramifica il ramo dal ramo principale se trovi un bug grave in una delle tue versioni (ad esempio "Se l'utente inserisce il codice konami, il nostro programma riformatterà l'hard disk principale ..."). Si ramifica dal rilascio del buggy e, quando la correzione è terminata, viene reimmessa nel ramo master AND nel ramo devlopment.

Questo è il corto, ma credimi, che l'articolo lo descrive in modo più dettagliato, e con l'utile grafica di visualizzazione è molto più facile da capire.

    
risposta data 23.12.2011 - 11:12
fonte
5

Il mio principio è che più a breve termine è il ramo, più profondo dovrebbe essere nella struttura del ramo e più specifico sarà il suo nome. Più a lungo termine il ramo è, meno profondo sarà nella struttura del ramo e più generico sarà il suo nome.

Quindi mantieni il master per la versione a lungo termine (3.X) e continui a nominare questo ramo con un nome generico (master, trunk, devel, ...) e non uno specifico (nome del codice di rilascio o anche numeri di rilascio peggiori che sono troppo dipendenti dalla pratica nella decisione di tardiva del bollettino)

Non importa tanto in un sistema come git che ha uno spazio di nome piatto per le filiali e dove i rami sono equivalenti. Importa di più con un sistema come clearcase che ha uno spazio dei nomi gerarchico per i rami (il nome completo del ramo V4 termina con main / v1 / v2 / v3 / v4 ...)

    
risposta data 23.12.2011 - 11:09
fonte

Leggi altre domande sui tag