Come metti sotto controllo le versioni versioni diverse della tua libreria? Usi i tag? O rami? O un altro metodo?

Di recente ho iniziato a mettere il mio codice sotto il controllo della versione (in laboratorio sto lavorando, sotto SVN, e i miei codici in github (ovviamente con git)). Prima di usare il controllo versione, facevo qualcosa del genere. Avevo una cartella con il nome della libreria, all'interno di molte cartelle con il numero di versione. Ogni volta che volevo iniziare a lavorare su una versione più recente, creavo una copia dell'ultima versione, cambiavo il nome con la nuova versione e iniziavo l'implementazione.

Questo tuttavia sembra ridondante quando la cartella viene messa sotto il controllo della versione. A parte la ridondanza, se qualcuno vuole ottenere l'ultima versione, sarebbero scaricando tutte le versioni se ha appena imports / clones.

Ora vedo molti modi per farlo con il controllo della versione, ma dato che sono nuovo, non so quale sarebbe più gestibile.

Metodo 1: utilizzo dei tag

Se avessi capito correttamente i tag, avresti il ​​tuo ramo principale, commetti qualsiasi modifica tu abbia e tagli con una versione. Quindi, quando vuoi ottenerne una copia funzionante, ottieni quella con un determinato tag. (correggimi se sbaglio)

Metodo 2: versioni ramificate

In questo metodo, il ramo principale sarebbe il ramo di sviluppo. Ogni tanto viene creata una versione stabile (diciamo v1.2.0), crei un ramo per quella versione e non ti impegni mai. In questo modo, se si desidera scaricare una determinata versione, si ottiene il codice da quel ramo. Anche se ho detto che non ti impegni mai, potrebbe essere possibile eseguire correzioni di bug e impegnarsi nel ramo di una versione precedente per mantenere in esecuzione la versione precedente. Ad esempio, se la versione corrente è v2.0, ma ci sono persone che vogliono usare v1.2, è possibile ottenere un altro ramo v1.2, vale a direv1.2.1 e commettere le correzioni di bug, o semplicemente mantenere la versione uguale v1.2e semplicemente commettere le correzioni di bug.

Quindi i rami sarebbero così:

                  v1.2.1  v1.2.2
                 /       /
 v1.0.0   v1.2.0---------     v2.0.0
/        /                   /
-------------------------------------- dev

In questo modo hai rami per ogni aggiornamento di versione minore. (Si noti che nel grafico sopra, v1.2.1 e v1.2.2 o creati dopo il rilascio di v2.0.0, quindi non facevano parte dello sviluppo tra v1.2.0 e v2.0.0. Considerarlo come supporto per le versioni precedenti)

Metodo 3: sviluppo ramificato

Questo metodo è l'opposto del precedente. Il ramo principale sarebbe l'ultima versione stabile. Ogni volta che lavori su una nuova versione, crei un ramo (per lo sviluppo), lavori sul tuo codice e quando è stabile, uniscilo con il ramo principale.

In questo caso, i rami sarebbero così:

 ________  ____  ________________  _____ dev
/        \/    \/                \/
---------------------------------- latest_version

Probabilmente questo deve essere fatto insieme ai tag giusto?

La domanda!

Comunque, la mia domanda è quella basata sulla tua esperienza, quale di questi metodi si rivela più pratico? Esiste un metodo migliore conosciuto là fuori (che forse non ho capito da solo)? Come si fanno comunemente queste cose?

Tag e rami non sono reciproci, è possibile (e IMO di solito dovrebbe) usarli entrambi. I tag sono lì per segnare le pietre miliari nello sviluppo. Ad esempio, si apre una filiale per la versione 1.2 del prodotto, e si segnano v1.2 Beta, RC1, RC2, Final(e poi, se necessario,SP1 ecc) con le etichette su quello stesso ramo.

Personalmente preferisco il Metodo 2 come approccio predefinito (anche se cerco di evitare più livelli di rami, per mantenere la vita il più semplice possibile). Il metodo 1 non funzionerà nella vita reale: i tag non sono sufficienti, hai bisogno di rami. E il metodo 3 non è flessibile in quanto ha una sola versione stabile in ogni momento, quindi (a meno che non lo si combini con il Metodo 2), non è possibile mantenere più versioni (più recenti e precedenti) in parallelo. Ciò è necessario per quasi tutti i progetti nella vita reale: mentre lavori alla versione 2, dovresti comunque essere in grado di pubblicare patch / aggiornamenti per la versione 1.9 e spesso anche versioni precedenti. Molto dipende ovviamente dal tipo di applicazione. Sviluppiamo un'app Web, quindi esiste una sola versione di produzione in un dato momento, ma spesso destreggiamo con 3 versioni diverse (una in produzione, uno è in UAT pronto per la distribuzione, uno è l'ultima versione sul trunk). Può diventare molto più complesso per un'app desktop / client con più versioni precedenti utilizzate e mantenute in parallelo.

Avevo una cartella con il nome della libreria, all'interno di molte cartelle con il numero di versione.

Questo è effettivamente, come noti, un approccio sbagliato, dal momento che hai già il controllo della versione per ... controllare le versioni.

Ora, diverse tecniche che enumerate sembrano tutte ugualmente giuste. Puoi leggere un articolo molto dettagliato, Controllo sorgente fatto a destra , che include informazioni su tag e rami.

I tre metodi non si escludono a vicenda e dovresti combinarli per ottenere il massimo dal controllo della versione.

Da parte mia, utilizzerei una combinazione di metodo 1 e 3 per impostazione predefinita, ovvero sviluppo in una funzione o in un ramo di sviluppo fino a quando una funzione non è pronta per la produzione e quindi si fonde nuovamente nel trunk. In questo modo, trunk rappresenta sempre lo stato attuale dello sviluppo stabile e da utilizzare e può essere tranquillamente collegato da svn: progetti esterni. Quando rilasci una versione, taggala.

Diramerei solo su richiesta, cioè quando le versioni precedenti della tua libreria hanno un bug che deve essere corretto. Puoi facilmente creare quel ramo dal tag della versione non funzionante. Non ramificando inutilmente, si mantiene basso il numero di rami e si ha una rapida visione d'insieme dei bordi sanguinanti che devono essere mantenuti (tronco e tutti i rami).

Vorrei usare il metodo 2 . L'ho usato e l'ho trovato un modo efficace per gestire e mantenere più versioni pur consentendo allo sviluppo attuale di andare avanti. Puoi anche usare i tag insieme a questo metodo se ne hai bisogno.

Vedere la mia risposta qui per ulteriori informazioni sull'uso delle diramazioni per mantenere più versioni di rilascio.