2016-06-14 78 views
9

Immaginiamo lo strumento da riga di comando blerp gestito su . Questo strumento ha l'opzione (nascosta) --version che restituisce il suo version (diciamo 0.1.2) e un altro --commit che restituisce il numero di commit da cui è stato generato.Come gestire il numero di versione in Git?

Sia la versione che il numero di commit sono hardcoded sulla base di codice.

Ora eseguo una correzione, quindi eseguo il commit e ricostruisco il mio programma. Vedrò comunque 0.1.2 sebbene questa nuova versione differisca dalla 0.1.2 originale. Solo il commit mi dirà che non è lo stesso 0.1.2. Quel bugfix vale un numero di versione diverso?

Una soluzione è che ogni volta che si effettua un commit, aumento il numero di versione codificato (che implica di modificare sempre almeno 2 file per ogni commit). Questa è una soluzione vincolante e non funziona quando gli sviluppatori lavorano su diversi rami attivi. Se Bob funziona sulla funzione foo dalla versione 0.1.2 e Alice funziona sulla funzione bar dalla stessa versione. Come aumentano il loro numero di versione? Bob può usare il dispari e Alice il pari. Cosa succede se Eve funziona su una terza funzione?

Un'altra soluzione può essere quella di utilizzare i tag Git per generare automaticamente il numero di versione. Uno script può trovare il tag più vicino a partire da v come v0.1.2 e utilizzare il nome del tag come numero di versione più le prime n cifre del commit corrente (v0.1.2 (build 4acd21)). Funziona bene se la directory di lavoro è pulita. Si può immaginare di aggiungere un * prima del numero di build per indicare che la directory di lavoro non è pulita. Il problema principale di questa soluzione è che se qualcuno esporta i sorgenti, non sarà in grado di creare blerp.

Quale possibile alternativa può risolvere questo problema?

+1

Di solito, si dovrebbe evitare di mettere una versione nei file di origine. Idealmente, si avrebbe un processo di compilazione che codifica la versione nel numero di build. In questo modo la versione è indipendente dal sorgente utilizzato per costruirlo. Quel processo può quindi anche codificare l'id di commit da qualche parte, in modo da sapere sempre da dove viene creata la fonte.E per quanto riguarda la memorizzazione del numero di versione, la soluzione comune è l'utilizzo dei tag. Questo ti dà anche il vantaggio che puoi facilmente navigare per versione nel tuo repository guardando i tag. – poke

+0

@poke Come si ottiene il numero di versione nel prodotto se si dispone di fonti esterne a SCM. Quale sarebbe la versione di 'blerp'? – nowox

+0

Di solito, la cosa che pubblichi non è esattamente nello stesso stato di quella del controllo di versione. Quindi puoi applicare la versione nel tuo processo di compilazione come ho descritto. – poke

risposta

5

Si prega di dare un'occhiata al comando git describe. Questo comando mostra l'ultimo tag e una quantità di commit effettuati dopo che il tag è stato impostato. È anche possibile mostrare la sporcizia del repository.

Come hai detto questo comando non funzionerebbe senza il repository git (cartella .git) e git installato.Ma è uno sviluppatore quasi inimmaginabile oggi senza git ma con tutti gli altri strumenti installati.

2

Come dici tu, i problemi di versioning vengono solitamente risolti in git usando branch e tags (come il modello semantic versioning).

Il modo migliore è utilizzare git per tenere traccia solo delle modifiche nella base di codice, ignorando (utilizzando il file .gitignore) i file e mantenendo un repository pulito.

Costruisce risultati (pre/file compilati, eseguibili, file di distribuzione, zip, exe ...) potrebbe dipendere di variabili ambienti (piattaforma, arco del sistema, ecc) e dovrebbe essere tenere separati in un registro.

Se il codebase è molto grande e difficile da mantenere, forse dovresti considerare di dividerlo in componenti più piccoli (o git submodule) per evitare interdipendenze in fase di sviluppo.

1

I numeri di revisione devono essere gestiti da voi, non da git. Dato che, contrariamente a SVN, non hai un numero di revisione incrementale in crescita su ogni commit, non c'è modo di git di contestualizzare quale sia la tua versione.

+1

Sì. Il nome git è un hash derivato dalle modifiche e non parla dei codificatori * intention *. Questa è una cosa rilasciabile, o semplicemente una sosta lungo la strada? Git non può saperlo. –

3

Alexey Kiselev e Dario già accennato alla risposta, ma proverò a spiegarlo in dettaglio.

di controllo delle versioni Schemi

Ci sono due tipi di versioning schemi

  1. numero di versione interno: Questo può essere incrementato molte volte in un giorno (ad esempio, di revisione di controllo Number)
  2. versione rilasciata: Questo cambia meno spesso (es. Versioning semantico)

persone usano different schemes come da lì bisogno, ma semantic versioning è abbastanza ampiamente utilizzato e scritto da Tom Preston-Werner, cofondatore di GitHub.

semantico delle versioni

delle versioni semantica segue schema di X.Y.Z

o più leggibile sarebbe [major].[minor].[patch]-[build/beta/rc]

esempio 1.2.0-beta

major or X può essere incrementata se ci sono grandi cambiamenti nel software, come all'indietro rilascio API incompatibile

minor or Y viene incrementato se vengono introdotti API compatibili all'indietro

patch or Z viene incrementato dopo una correzione errore.

Come ottenere ciò utilizzando Git?

utilizzando tag: Tag in git può essere utilizzato per aggiungere il numero di versione.

git tag -a "v1.5.0-beta" -m "version v1.5.0-beta"

aggiunge un tag versione di v1.5.0-beta al vostro git attuale repo.Every nuovo commit dopo questo si auto incrementato aggiungendo commettere numero e commettere hash per questo tag. Questa può essere vista utilizzando il comando git describe.

qui -1- è il numero di commit e 0c4f33f l'abbreviazione di hash del commit. Il prefisso g sta per "git".

dettagli completi possono essere visualizzati con

git show v1.0.5-beta

Problemi correlati