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

Ho alcune applicazioni software gestite usando Git. Ho appena rilasciato una nuova versione 2.x che prevedo di mantenere a lungo termine (principalmente correzioni di bug). 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 viceversa?

version-control git

— laurent
fonte

Hanno rami diversi per lo sviluppo e stabili.

— Oded,

Quindi cosa succede di solito nel ramo principale? (fino ad ora faccio sempre tutto lì)

— laurent

Devi decidere cosa vuoi masterdire. È solo un'etichetta.

— Oded,

Risposte:

Qui è stato descritto un modo molto interessante di fare le cose: un modello di ramificazione Git di successo

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

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

Il ramo Master rappresenta solo tutti i traguardi raggiunti (ovvero versione 1.0, 1.1, 1.2 ecc.)
Lo sviluppo avviene nel suo ramo (convenientemente chiamato "sviluppo", chi l'avrebbe mai pensato?). Il ramo di sviluppo viene unito nuovamente al ramo principale, ogni volta che viene eseguita una versione completa di funzionalità.
La ramificazione dallo sviluppo sono rami delle caratteristiche. Queste rappresentano singole funzionalità per la prossima (o futura) versione. Si fondono con il ramo di sviluppo.
Un altro ramo proveniente dallo sviluppo è il ramo "rilascio". 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 infine con il ramo principale
"Hotfix" si ramifica dal ramo master se trovi un bug grave in una delle tue versioni (es. "Se l'uso inserisce il codice konami il nostro programma riformatterà il disco rigido principale ..."). Si ramifica dalla versione buggy e, quando la correzione è terminata, viene nuovamente unita nel ramo principale E nel ramo di sviluppo.

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

— Sorcy
fonte

Dovresti includere alcune spiegazioni sul tuo suggerimento nella risposta, preferibilmente le persone non dovranno seguire il link per avere un'idea generale del modello. I legami hanno la cattiva abitudine di diventare stupidi e le risposte dovrebbero stare da sole ...

— yannis,

+1 Praticamente quello che usiamo al lavoro e funziona davvero.

— Ed James,

Credo che questo sia comunemente definito il modello "trunk stabile" o "ramo delle caratteristiche".

— sleske,

"Il ramo Master rappresenta solo tutti i traguardi raggiunti (ovvero la versione 1.0, 1.1, 1.2 ecc.)" Non vorrei un ramo master con le versioni 1.0, 1.1, 1.2, 2.0, 1.3, 2.1, 1.4, 2.2, 3.0, 1.5 in quell'ordine, sarebbe davvero confuso. La mia ipotesi è che c'è un'ipotesi implicita che esista al massimo un flusso su cui vengono eseguite le versioni, non è il caso nella mia pratica. Ci sono primi utenti e persone che vogliono qualcosa di più stabile.

— AProgrammer

Bene, a lungo termine un ramo non è altro che un'etichetta per renderti più facile sapere cosa sta succedendo lì. Quindi, se non ti piace in questo modo, non c'è nulla che ti impedisca di utilizzare il ramo Master solo per versioni stabili sindaco e avere un ramo "Trial" (o come vuoi chiamarlo) per versioni incrementali più piccole.

— Sorcy,

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

Quindi mantieni il tuo 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 numeri di versione ancora peggiori che sono troppo dipendenti in pratica dalla decisione di commercializzazione tardiva)

Non importa così tanto in un sistema come git che ha uno spazio dei nomi piatto per i rami 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 finisce per essere main / v1 / v2 / v3 / v4 ...)

— AProgrammer
fonte

+1 tranne che non so cosa significhi davvero in questo contesto profondo e superficiale, forse potresti espandere un po 'quei termini?

— Michael Durrant,

Pensa ai rami che fanno un albero. Possono uscire dal tronco o da un altro ramo. Poco profondo significa che il numero di passi di ramificazione tra il ramo e il tronco è piccolo, profondo significa che il numero di passi di ramificazione è importante. Ciò che è piccolo e importante è per lo più relativo, ma ho visto schemi per i quali ogni nuova versione era un passo avanti rispetto alla precedente dal bagagliaio. Se stai usando uno spazio dei nomi piatto, non è poi così male. Se lo spazio dei nomi è gerarchico (clearcase, CVS, RCS, Perforce possono essere utilizzati anche in questo modo), si ottengono nomi sempre più lunghi.

— Approgrammatore