W jaki sposób semantyczna wersja pasuje do przepływu pracy git?

Question

Obecnie mam problemy z używaniem wersji semantycznej z git.

Używamy model wersjonowania git na http://nvie.com/posts/a-successful-git-branching-model/

Chcielibyśmy także, aby postępować zgodnie z wytycznymi wersjonowania semantyczne nakreślonych w http://semver.org/

Oto przykładowy przypadek użycia dla nas.

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

Oto nasz przypadek użycia próbki:

• Rozwój następuje równolegle z wydaniem i rozwijać
• wydanie jest gotowe, możemy oznaczyć go jako v1.2. Generujemy notatki do wydania zmian 1, 2, 3, 4.
• Łączymy release, aby się rozwinąć.
• Kiedy jesteśmy gotowi, aby rozwinąć gałąź na kolejną wersję, możemy. Jednak znacznik v1.2 wskazuje na 4, więc informacje o wersji dla 5 zostaną utracone, jeśli będziemy pytać o zmiany między wersją 1.2 a wersją 1.3

To, co chcielibyśmy zrobić, to móc szukaj wszystkich nowo dodanych checkinów, odkąd utworzono tag v1.2, który został nowo dodany do tagu v1.3, abyśmy mogli określić, jaki rodzaj wersji bump (xyz) dla naszego komponentu musimy wprowadzić.

Jeśli 5 okazało się poważną zmianą, ale wszystko od wersji 1.2 nie jest, niepoprawnie naruszymy wersję dodatkową, ponieważ zaznaczenie 5 nie było w kompilacji.

Czy ktoś ma jakieś sugestie, w jaki sposób można to rozwiązać?

Answer 1

To zależy od tego, jak "wyszukujesz zmiany". Ale jeśli masz na myśli używanie git log v1.2..v1.3, lub coś w tym stylu, to powinno ci pokazać dokładnie, co chcesz, to znaczy, włączając commit 5.