Come si ottiene uno schema di controllo numerico con Git?

Utilizza i tag per contrassegnare i commit con i numeri di versione:

git tag -a v2.5 -m 'Version 2.5'

Spingi i tag a monte - questo non è fatto di default:

git push --tags

Quindi utilizza il descrizione del comando:

git describe --tags --long

Questo ti dà una stringa del formato:

v2.5-0-gdeadbee
^    ^ ^^
|    | ||
|    | |'-- SHA of HEAD (first seven chars)
|    | '-- "g" is for git
|    '---- number of commits since last tag
|
'--------- last tag

Questo mi è venuto in mente su alcuni progetti. La soluzione migliore che ho avuto finora è di generare un numero di versione come questo:

x.y. < numero di commit > .r < git-hash >

Generalmente viene generato dal nostro sistema di build utilizzando una combinazione di alcuni file o tag statici per ottenere i numeri di revisione principali, git rev-list HEAD | wc -l (che era più veloce dell'utilizzo di git log ) e git rev-parse HEAD . Il ragionamento era il seguente:

1. Avevamo bisogno della possibilità di avere il versioning di alto livello che si verificava esplicitamente (cioè x.y)
2. Quando avveniva lo sviluppo parallelo, non dovevamo MAI generare lo stesso numero di versione.
3. Volevamo facilmente rintracciare da dove proviene una versione.
4. Quando le linee parallele sono state unite, volevamo che la nuova versione si risolvesse più in alto di uno dei rami.

Il numero 2 è invisibile alla maggior parte delle persone, ma è veramente importante e veramente difficile con il controllo del codice sorgente distribuito. SVN ti aiuta dandoti un numero di revisione singolo. Si scopre che un conteggio dei commit è il più vicino possibile, mentre si risolve magicamente anche il # 4. In presenza di rami, questo non è ancora univoco, nel qual caso aggiungiamo l'hash, che risolve nettamente anche il n. 3.

La maggior parte di questo era per ospitare la distribuzione tramite pip di Python. Ciò garantiva che pip install sarebbe stato un po 'strano durante lo sviluppo parallelo (cioè i pacchetti da persone su rami diversi si sarebbero mescolati, ma in modo deterministico), ma che dopo l'unione, tutto risolto. Escludendo la presenza di un rebase esposto o di modifica, questo ha funzionato abbastanza bene per i requisiti di cui sopra.

Nel caso ve lo stiate chiedendo, abbiamo scelto di mettere la r davanti all'hash a causa di alcune stranezze con il modo in cui la confezione Python gestisce le lettere nei numeri di versione (cioè ae sono minori di 0, il che renderebbe "1.3.10. a1234 "<" 1.3.10 "<" 1.3.10.1234 ").

Le versioni sono identificate con l'hash SHA1 di tutti i file nella struttura della directory memorizzata al momento del check-in. Questo hash è memorizzato insieme agli hash dei controlli parent (i) in modo da poter leggere l'intera cronologia.

Dai un'occhiata al processo di utilizzo di 'git-describe' per mezzo di GIT-VERSION-GEN e come puoi aggiungerlo tramite il processo di compilazione quando tagghi il tuo rilascio.

Ecco un bel blog che fornisce un esempio di come ottenere ciò che desideri:

link

Questo potrebbe essere un po 'eccessivo, ma ti farò sapere come lo facciamo.

Utilizziamo una struttura di ramificazione molto simile a questo .

Hudson costruisce i rami "sviluppa" e incrementa i numeri di build a partire da 0. Il numero di build è unico per ogni progetto e viene taggato nel controllo della versione. Il motivo è che puoi dire esattamente da quale sviluppo proviene il ramo build 42, ad esempio (ogni progetto può avere diversi rami di sviluppo in parallelo, perché ogni progetto può avere diversi team che lavorano su diversi aspetti del progetto).

Quando decidiamo che una particolare build è sufficiente per essere rilasciata, il commit che ha attivato quella build viene taggato con un numero di versione della release, che viene deciso dal marketing. Ciò significa che i team di sviluppo non si preoccupano di quale sia il numero di versione finale e il marketing è libero di mescolare i numeri di versione come meglio crede. Il numero di versione finale e il numero di build sono entrambi presenti nel prodotto rilasciato.

Esempio: 2.1.0 build 1337

Questo significa che, per una specifica versione del prodotto, puoi dire quale è stato l'ultimo team a lavorarci e puoi interrogare git per tutti i commit che portano al rilascio per diagnosticare un problema se necessario.

Pro Git in sezione 7.2 "Attributi Git" in "Parola chiave" Parte di espansione contiene un bell'esempio di utilizzo di filtri sfumati e puliti per generare parole chiave in stile RCS. Puoi utilizzare la stessa tecnica per incorporare some-version-string in codice, formattato e calcolato in base alle tue regole . Puoi ancora poter usare git describe come punto di partenza, ma hai la possibilità di trasformarti in un modulo più appropriato e ottenere da v2.5-14-feebdaed, ad esempio, clean 2.5.14