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

Naviga le tue risposte
23

Recentemente ho iniziato a mettere il mio codice sotto controllo di versione (in laboratorio sto lavorando, sotto SVN, e i miei codici in github (ovviamente con git)). Prima di usare il controllo della versione, facevo qualcosa del genere. Ho avuto 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, eseguivo una copia dell'ultima versione, cambia il nome nella nuova versione e inizio all'implementazione.

Questo tuttavia sembra ridondante quando la cartella viene messa sotto controllo di versione. A parte la ridondanza, se qualcuno vuole ottenere l'ultima versione, scaricherà tutte le versioni se solo import s / clone s.

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

Metodo 1: utilizzo dei tag

Se ho capito i tag correttamente, avresti il tuo ramo principale, hai commesso qualsiasi cambiamento hai ottenuto e taggali con una versione. Quindi, quando vuoi ottenere una copia funzionante, ottieni quella con un determinato tag. (correggimi se sbaglio)

Metodo 2: versioni di ramificazione

In questo metodo, il ramo principale sarebbe il ramo di sviluppo. Ogni tanto viene creata una versione stabile (diciamo v1.2.0 ), si crea un ramo per quella versione e non ci si impegna mai. In questo modo, se vuoi scaricare una certa versione, ottieni il codice da quel ramo. Sebbene abbia affermato che non ci si è mai impegnati, potrebbe essere possibile eseguire correzioni di bug e eseguire il commit sul ramo di una vecchia versione per mantenere in esecuzione la versione precedente. Ad esempio se la versione corrente è v2.0 , ma ci sono persone che vogliono usare v1.2 , puoi ottenere un altro ramo da v1.2 , ovvero v1.2.1 e commettere le correzioni di errori, o semplicemente mantenere la versione stessa come v1.2 e commetti solo le correzioni dei bug.

Quindi i rami dovrebbero assomigliare a questo: 

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

In questo modo hai filiali per ogni aggiornamento della versione secondaria. (Si noti che nel grafico sopra, v1.2.1 e v1.2.2 o creato dopo v2.0.0 è stato rilasciato, quindi non facevano parte dello sviluppo tra v1.2.0 e v2.0.0. Consideralo 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 stai lavorando 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 dovrebbero assomigliare a questo: 

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

Probabilmente questo deve essere fatto insieme ai tag giusto?

La domanda!

Ad ogni modo, la mia domanda è che in base alla tua esperienza, quale di questi metodi si dimostra più pratico? C'è un metodo migliore conosciuto là fuori (che forse non ho capito io stesso)? Come sono comunemente fatte queste cose?

    
posta Shahbaz 29.09.2011 - 15:51
fonte

4 risposte

16

Tag e rami non sono reciproci, puoi (e IMO di solito dovrebbe) usarli entrambi. I tag sono lì per contrassegnare le pietre miliari nello sviluppo. Per esempio. apri un ramo per la versione 1.2 del tuo prodotto e contrassegni v1.2 Beta , RC1 , RC2 , Final (e poi, se necessario, SP1 ecc.) con i tag sullo 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 qualsiasi momento, quindi (a meno che non lo si combini con il Metodo 2), non è possibile mantenere più versioni (più recenti e più vecchie) in parallelo. Questo è richiesto per quasi tutti i progetti nella vita reale - mentre si sta lavorando sulla versione 2, si dovrebbe comunque essere in grado di pubblicare patch / aggiornamenti per la v1.9, e spesso anche per le versioni precedenti. Molto dipende dal tipo di applicazione, ovviamente. Sviluppiamo un'app Web, quindi esiste una sola versione di produzione in un dato momento, tuttavia spesso giochiamo con 3 diverse versioni (una in produzione, una in UAT è pronta per l'implementazione, una è l'ultima versione sul trunk ). Può diventare molto più complesso per un'app desktop / client con più versioni precedenti utilizzate e mantenute in parallelo.

    
risposta data 29.09.2011 - 16:03
fonte
6

I had a folder with the name of the library, inside many folders with the version number.

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

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

    
risposta data 29.09.2011 - 16:02
fonte
3

I tre metodi non si escludono a vicenda e dovresti combinare i tre metodi per ottenere il massimo dal tuo controllo di versione.

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

Mi aggirerei solo su richiesta, cioè, quando le versioni precedenti della tua libreria hanno un bug che ha da correggere. Puoi facilmente creare quel ramo dal tag della versione spezzata. Non ramificandoti inutilmente, tieni basso il numero di rami e ottieni una rapida panoramica sui bordi sanguinanti che devono essere mantenuti (tronco e tutti i rami).

    
risposta data 29.09.2011 - 16:32
fonte
2

Vorrei utilizzare Metodo 2 . Ho usato questo e ho trovato che fosse un modo efficace per gestire e mantenere più versioni pur consentendo allo sviluppo attuale di andare avanti. Puoi anche utilizzare i tag insieme a questo metodo se ne hai bisogno.

Vedi la mia risposta qui per ulteriori informazioni sull'utilizzo della ramificazione su mantenere più versioni di rilascio.

    
risposta data 29.09.2011 - 16:18
fonte

Leggi altre domande sui tag

Dividere il progresso della codifica in commit significativi senza troppi sovraccarichi Repository DDD nell'applicazione o nel servizio di dominio