Cómo funciona el control de versiones semántico en el flujo de trabajo de git

Question

Actualmente estoy teniendo problemas para usar versiones semánticas con git.

Estamos utilizando el modelo de control de versiones Git en http://nvie.com/posts/a-successful-git-branching-model/

También nos gustaría seguir las directrices de versiones semánticos descritos en http://semver.org/

A continuación se muestra un caso de uso para nosotros.

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

Aquí es nuestro caso de uso de ejemplo:

• El desarrollo ocurre en paralelo en la liberación y desarrollar
• lanzamiento está listo para ir, etiquetamos como v1.2. Generamos notas de la versión para los cambios 1, 2, 3, 4.
• Combinamos la liberación de nuevo para desarrollar.
• Cuando estamos listos para la rama de desarrollar nuevamente para otra versión, podemos. Sin embargo, v1.2 etiqueta está apuntando a 4, por lo que las notas de la versión para 5 se pierde eficacia si consultamos los cambios entre la versión 1.2 y la versión 1.3

Lo que nos gustaría hacer es ser capaz de busque todos los checkins recién agregados desde que se creó la etiqueta v1.2 que se incorporó recientemente en la etiqueta v1.3 para que podamos determinar qué tipo de bache de versión (xyz) necesita para nuestro componente.

Si sucedió que un cambio importante sucedió en 5, pero no todo lo de v1.2 en adelante, toparemos incorrectamente con la versión menor ya que checkin 5 no estaba en la compilación.

¿Alguien tiene alguna sugerencia sobre cómo se puede resolver esto?

Answer 1

Supongo que eso depende de cómo "consultar para cambios". Pero si usted quiere decir usando git log v1.2..v1.3, o algo por el estilo, a continuación, que en caso de que muestran exactamente lo que quiere, es decir, incluyendo cometer 5.