Incrementos de revisión de rama/maestra usando Git

Question

Estoy tratando de establecer un buen sistema para la gestión de lanzamientos, combinado con la práctica de etiquetado con números de versión, por ejemplo, 1.0. Cualquier cambio posterior a esa etiqueta se incrementará, como 1.0-1, 1.0-2, etc.

Sin embargo, si creo una nueva rama de master para la versión 1.0, y luego cambio a esa rama y la etiqueto 1.0, el sistema como se mencionó anteriormente funciona bien. Correcciones adicionales de errores en esa rama muestran como se esperaba, 1.0-1, 1.0-2

Sin embargo, cualquier trabajo en el maestro, a menos que vuelva a etiquetar el maestro después de la primera confirmación después de hacer la rama 1.0, también mostrará el mismo incremento: 1.0-1, 1.0-2

por supuesto, los valores hash SHA1 será único, pero me gustaría llegar a tener las mismas revisiones/incrementos tanto de maestro y la rama.

¿Hay alguna manera de evitar la maestría de ser tocado en absoluto cuando acabo de etiquetar las ramas? ¿Hay alguna forma mejor de hacer esto? En este momento, mi única opción después de hacer la rama 1.0 es hacer una confirmación menor en el maestro, y luego volver a etiquetarla para 1.1-dev o algo así.

Luego repita para cada lanzamiento.

Sin embargo, si una rama está etiquetada entonces de nuevo, digamos por la liberación 1.0.1, eso también parece que sería también etiquetar maestro ya que eso es lo que pasó en primer lugar?

Answer 1

En Git no se etiquetan las ramas. Usted etiqueta commits. Si desea "marcar" una rama, ya la obtuvo: el nombre de la sucursal. :)

Sí, git describe le da identificadores de confirmación como 1.0-2-g1ab3183 pero esas no son etiquetas! El etiquetado se realiza con git tag (quién lo hubiera adivinado), y las etiquetas que se crean usando git tag son la base para los identificadores de confirmación git describe crea.

Answer 2

En git Una etiqueta es un alias para un específico cometió, no para una rama.

Las etiquetas y las ramas son independientes.

Así que si usted quiere obtener una versión específica para hacer un rev de menor importancia en ella, luego se podía hacer:

git checkout -b new_branch_name commit_id 

O

git checkout -b new_branch_name tag_name 

Ambas son formas simplemente equivalentes de referirse a una compromiso específico.

realizar los cambios, cometerlos y la etiqueta del comprometen con el rev menor.

Incluso podría eliminar la bifurcación que desprotegió.

Answer 3

En Git no se puede decir que algunos commit pertenece a alguna rama. La confirmación única puede estar en más de una rama; si commit A es uno de los ancestros de tip of branch, decimos que está en una rama determinada.

Como Bombe said en Git no etiquetar las ramas. Usted etiqueta commits. En la etiqueta de Git es solo un apuntador (anotado) a una confirmación.

En el caso de tener, creo, algo así como lo siguiente

 
         /-- [v1.0] 
         v 
---.---.---.---X---.---A  <-- master 
         \ 
          \-.---B  <-- maint 

Comprometámonos 'X' se comit señalado por etiqueta 'v1.0'. Esta confirmación se realiza tanto en la rama 'master' como en la rama 'maint'. Si ejecuta "git describe" encima de confirmar 'A' (parte superior de la rama 'principal') obtendrá algo como v1.0-2-g9c116e9. Si ejecuta "git describe" encima de commit 'A' (rama 'maint') obtendrá algo como v1.0-2-g3f55e41 (al menos con la configuración predeterminada de git-describe). Tenga en cuenta que este resultado es ligeramente diferente. v1.0-2-g9c116e9 significa que estamos en confirmación con la identificación SHA-1 minimizada de 9c116e9, 2 confirmaciones después de la etiqueta v1.0. ¡No hay etiqueta v1.0-2!

Si desea que la etiqueta aparezca solo en la rama 'master', puede crear nueva confirmación (por ejemplo, actualizar la información de versión predeterminada/alternativa en GIT-VERSION-FILE) después del punto de bifurcación de la rama 'maint'. Si etiqueta los commits en la rama 'maint' con, p. 'v1.0.3` sería visible solo desde' maint '.

HTH