Correzione delle versioni e correzione dei bug legacy in un SCM

Question

Mi dispiace molto per il titolo terribile della domanda, ma proverò a spiegarmi un po 'più verbalmente:

Sto usando Git (ma immagino che il software specifico non contenga davvero in questo caso) per il mio progetto software. Come molti progetti, sto pensando di avere varie versioni. In caso di rilascio, probabilmente assegnerei un commit a tag - ad esempio "quot" 1.0 ". Il tempo passa e il codice viene violato, e alla fine c'è un rilascio, con un altro tag - questa volta "2.0".

Un giorno, noto un bug grave, presente in entrambe le versioni 1.0 e 2.0, e deve essere corretto. Per rendere le cose difficili (e probabilmente anche più realistiche), non posso semplicemente risolverle nell'attuale master / trunk e presumere che tutti lo userebbero, perché ci sono alcune incompatibilità all'indietro in 2.0 con 1.0 e le persone sono pigre e don non voglio aggiornare.

Quindi, quale sarebbe un buon schema da avere, al fine di supportare questo tipo di comportamento: essere in grado di apportare modifiche nelle versioni precedenti. Git sembra equiparare i tag con le versioni a un certo livello, a causa dell'output del comando git descritto (" [ultimo tag] - [commit dal tag] - [hash commit corrente] "). Quindi probabilmente non posso evitare di usare del tutto i tag.

Sento che una combinazione di tag e rami sarebbe una buona idea, ma per qualche ragione non posso avvolgere la testa attorno ai dettagli con questo.

Answer 1

Sicuramente vuoi esaminare come usare un ramo per questo. Git supporta molto bene i rami per questo tipo di sviluppo.

A titolo di esempio, la cronologia delle versioni lineare potrebbe apparire così:

---A---B---C[1.0]---D---E---F[2.0]---G---H

Se trovi un bug in 1.0 e vuoi risolverlo, non puoi semplicemente inserire un nuovo commit tra i commit C e D. Quindi, potresti creare un ramo come questo:

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]

I commit C1 e C2 risolvono il problema in quel ramo, dove è possibile taggare la versione 1.1. Supponiamo ora di aver apportato una modifica (G) nella versione 2.1 che desideri eseguire il backport alla versione 1.1 per apportare la stessa modifica lì. Puoi usare git cherry-pick per fare quanto segue:

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]---G1[1.2]

Il commit di G1 è correlato al commit G, tranne che può essere applicato alla versione 1.1 anziché alla versione 2.0.

In questi esempi, i rami (flussi aggiuntivi di sviluppo) sono il concetto chiave, mentre i tag sono solo un modo conveniente per fare un nome per fare riferimento allo stato in cui si trovava il progetto in un determinato momento. Git supporta molti altri modi di manipolare i rami, in particolare con il potente comando git rebase .

Answer 2

È necessario un ramo: eseguirai correzioni e rilasci di manutenzione su un ramo che inizia dal tag di rilascio, mentre lo sviluppo in corso continua sul ramo principale (principale).

Answer 3

Sembra che tu abbia già la maggior parte della risposta quando menzioni rami e tag. Un tag è lì per contrassegnare un certo pari (come un rilascio) e i rami sono destinati allo sviluppo parallelo. La manutenzione di una determinata versione viene generalmente eseguita su una diramazione e puoi modificare i corredi con la maggior parte del VCS corrente per importare una determinata correzione di bug da head / trunk in una diramazione e viceversa.

Puoi lavorare su head / trunk / master (come si chiama il ramo di sviluppo "corrente") e unire le correzioni dei bug nei vari rami di manutenzione. Non appena viene eseguita una versione principale o secondaria, si crea un ramo per la manutenzione.

Esistono molti modi per ottenere ciò che desideri.