¿Por qué debería usar etiquetas en lugar de ramas de versión / beta para el control de versiones?

114

He estado usando git durante aproximadamente un año y me gustaría usar el etiquetado para, bueno, etiquetar confirmaciones en diferentes versiones. Encontré mucha información sobre los comandos para usar para trabajar con etiquetas, pero lo que me gustaría saber es por qué usar el etiquetado si puedo crear una nueva rama llamada 1.1.0y no tener que nublar mi mente con un nuevo conjunto de comandos git?

Tiene que haber muchas buenas razones para etiquetar en lugar de ramificar, pero me gustaría saber cuáles son esas ventajas.

git branch git-tag

— wufoo
fuente

96

Las etiquetas se utilizan principalmente para futuras referencias a la versión específica del proyecto, etiquetando una confirmación. Siempre puede usar ramas, por supuesto, pero si cambia mucho las versiones, terminará con muchas ramas sin usar o que rara vez se usan.

Prácticamente, las etiquetas son ramas sin ramas de todos modos, solo agregan una forma de hacer referencia a una versión específica del proyecto para reducir la complejidad.

Editar: Aquí hay una buena forma de usar git que uso para todos mis proyectos.

— Hakan Deryal
fuente

Je (: Es realmente un gran flujo de trabajo que cubre todas las soluciones posibles.

— Hakan Deryal

sí, he visto el método nvie antes y me ha desconcertado bastante. No obstante, aspiro a implementarlo una vez que lo entienda. Supongo que con una etiqueta, no puedes cambiar accidentalmente el código, confirmar y seguir teniendo la misma versión. Con las ramas, puede ocurrir inadvertidamente. Las etiquetas parecen ser una forma más segura de marcar lanzamientos.

— wufoo

2

La belleza del método nvie para mí era que no necesitaba entenderlo inicialmente. Pude encontrar la sección de lo que quería hacer y escribir los comandos. Después de unas cuantas veces se convirtió en algo natural y en unos días estaba bailando alrededor de las ramas como un profesional.

— Killroy

Esperar comprender el enfoque de gitflow con solo aplicarlo a ciegas hará que se pierda todas las simplificaciones que podría aplicar a su situación. Y gitflow es de hecho inadecuado para la mayoría de los equipos: demasiado complejo o demasiado simple.

— toolforger

151

Una etiqueta es inmutable .

Mientras que puede crear una rama llamada "1.0.0", usted, o cualquier persona con derechos de confirmación, también puede simplemente presionar esa rama (deliberadamente o no) y cambiar el significado de 1.0.0.

No puede hacer eso con una etiqueta, una vez que crea una etiqueta, eso es todo; La etiqueta 1.0.0 significa exactamente eso y no se puede cambiar ^* .

Esa es la principal diferencia práctica entre una etiqueta y una rama.

^* Puede eliminar y volver a crear una etiqueta cambiando así una etiqueta, pero ciertamente no por accidente.

— AD7six
fuente

18

Tiendo a utilizar un flujo de trabajo que incorpora etiquetas y ramas. Las etiquetas son buenas para marcar código publicado o compilaciones de desarrollo notables. Las sucursales son buenas para realizar un seguimiento de todos los cambios relevantes para una versión específica.

Aquí hay una buena reseña sobre este tipo de flujo de trabajo: http://nvie.com/posts/a-successful-git-branching-model/

— Justin ᚅᚔᚈᚄᚒᚔ
fuente

18

La rama y la etiqueta son lo mismo (puntero a una confirmación, también conocido como "ref" ), excepto que la rama se mueve automáticamente a la siguiente confirmación mientras que la etiqueta permanece para siempre ¹ en la misma confirmación.

Al hacer un lanzamiento, generalmente desea marcar la "instantánea" del código a partir del cual se creó ese lanzamiento, y desea que permanezca marcado de esa manera incluso mientras continúa evolucionando el código, por lo que debe usar una etiqueta.

Si intentó usar una rama para eso, podría pasar inadvertidamente a una confirmación diferente, a partir de la cual no se creó la versión .

¹ A menos que elimine la etiqueta, por supuesto.

NOTA: Me doy cuenta de que esta es una pregunta antigua, pero sentí que la similitud (y una diferencia crucial) entre las ramas y las etiquetas no se ha desarrollado en otras respuestas con tanta claridad como podría haber sido.

— Branko Dimitrijevic
fuente

Estimado @ votante negativo, ¿alguna razón específica para el voto negativo?

— Branko Dimitrijevic

No voté negativamente por tu respuesta, pero ¿qué quieres decir con "la rama se mueve automáticamente a la siguiente confirmación"? Las ramas no se mueven automáticamente a ninguna confirmación. La ejecución git commitactualiza el encabezado de la rama extraída para hacer referencia a la nueva confirmación, sí, pero ninguna otra rama se mueve "automáticamente" a la siguiente confirmación. Debería aclarar el primer párrafo de su respuesta.

— Cepillo de dientes

1

@Toothbrush Seguro, eso es lo que quise decir con "se mueve automáticamente". Sin embargo, la rama realmente no "posee" ninguna confirmación, ni siquiera apunta a un conjunto de confirmaciones, solo apunta a una confirmación (y el resto puede estar implícito, a veces de manera imprecisa, al recorrer el gráfico de confirmaciones). En git, branch es solo un archivo de una línea que .git\refs\headscontiene el hash de la confirmación. Los propios comprometidos no "recuerdan" qué rama los creó. Esto es diferente de Mercurial, por ejemplo, donde la información de la rama se puede escribir en los metadatos de la confirmación.

— Branko Dimitrijevic

Sí, pero mucha gente no lo sabe, especialmente los recién llegados que están confundidos acerca de la gran cantidad de formas que se sugieren en línea para hacer cosas con Git.

— Cepillo de dientes

6

Utiliza etiquetas para anotar confirmaciones importantes en el historial. "Este fue el compromiso exacto que usamos para esta versión ese jueves lluvioso cuando se rompió el servidor de compilación". Si usa una rama en lugar de una etiqueta, nunca podrá saber qué confirmación exacta usó. Solo sabe "Lanzamos la versión 1.1.0 en algún lugar de esta rama", a menos que anote manualmente el hash exacto para esa confirmación, por lo que usa etiquetas en primer lugar :)

— ralphtheninja
fuente

4

Creo que se refería a crear una rama llamada 1.1.0 y no usarla más, por lo que representará el proyecto en la versión nombrada.

— Hakan Deryal

2

Además de las otras respuestas, aquí están mis 2 centavos.

Respuesta corta: use etiquetas para versiones de lanzamiento

Respuesta larga: Creo que usar etiquetas para versiones de lanzamiento específicamente es mejor que usar ramas. Si necesita actualizar el relase, simplemente bifurque la confirmación etiquetada y una vez que termine de trabajar en esa rama (probablemente una rama de revisión), cree una nueva etiqueta en el encabezado de esa nueva rama con la nueva versión. Luego, vuelva a fusionar esa rama en master / development porque realmente no debería cambiar una versión de lanzamiento a menos que sea una revisión que probablemente debería fusionarse nuevamente en su código fuente. Luego elimine esa rama ya que ya no es necesaria. Si necesita aplicar otra revisión a esa nueva versión, repita los mismos pasos.

Consulte la sección del siguiente artículo que muestra cómo combinar una revisión con el flujo de trabajo de Git del autor: https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2

— Región39
fuente