Come la versione semantica si adatta al flusso di lavoro git

Question

Attualmente sto riscontrando problemi nell'utilizzo della versione semantica con git.

Stiamo usando il modello di controllo delle versioni git a http://nvie.com/posts/a-successful-git-branching-model/

Vorremmo anche seguire le linee guida delle versioni semantici delineati in http://semver.org/

Ecco un caso d'uso di esempio per noi.

Release branch: ----1----2----3----4 <- tag v1.2  ----7---8---9 <- tag v1.3 
       /    \    /   \ 
Develop branch: --0--------5---------4--6-----------------------------9-- 

Ecco il caso di utilizzo di esempio:

• sviluppo avviene in parallelo sul rilascio e sviluppare
• di uscita è pronto ad andare, ci contrassegnatela come v1.2. Generiamo note di rilascio per le modifiche 1, 2, 3, 4.
• Uniamo nuovamente il rilascio per lo sviluppo.
• Quando siamo pronti per il ramo di sviluppo di nuovo per un'altra versione, possiamo. Tuttavia, il tag v1.2 punta a 4, quindi le note di rilascio per 5 vengono effettivamente perse se chiediamo modifiche tra v1.2 e v1.3

Quello che vorremmo fare è essere in grado di cerca tutti i nuovi check-in aggiunti da quando è stato creato il tag v1.2 che sono stati incorporati di recente nel tag v1.3 in modo da poter determinare il tipo di versione di bump (xyz) per il nostro componente che dobbiamo realizzare.

Se 5 è stato un grosso cambiamento, ma tutto dalla v1.2 in poi non lo è, scorreremo erroneamente la versione secondaria poiché il checkin 5 non era nella build.

Qualcuno ha qualche suggerimento su come questo può essere risolto?

Answer 1

Immagino che dipenda da come "chiedi i cambiamenti". Ma se intendi usare git log v1.2..v1.3, o qualcosa del genere, allora questo dovrebbe mostrarti esattamente quello che vuoi, cioè includere il commit 5.