Comprobar la etiqueta Git lleva al "estado HEAD separado"

166

Estoy desarrollando un script de implementación para mi proyecto git y recién comencé a usar etiquetas. He agregado una nueva etiqueta llamada v2.0:

git tag -a v2.0 -m "Launching version 2.0"

Y he enviado esta etiqueta al repositorio remoto

git push --tags

Cuando intento ejecutar el script de implementación y verifico la v2.0etiqueta, aparece este mensaje:

Estás en estado de 'CABEZA separada' Puede mirar a su alrededor, realizar cambios experimentales y confirmarlos, y puede descartar cualquier confirmación que realice en este estado sin afectar ninguna rama al realizar otro pago. Si desea crear una nueva rama para retener las confirmaciones que crea, puede hacerlo (ahora o más adelante) utilizando -b con el comando de pago nuevamente. Ejemplo: git checkout -b new_branch_name HEAD ahora está en

¿Eso es normal? El repositorio está en el limbo porque si lo hago:

git branch

Me sale esta salida:

* (no branch)
  master

Lo siento si esto es obvio, pero no pude resolverlo.

git deployment git-tag

— Khriz
fuente

Cuando dice "ejecutar el script de implementación y verificando la v2.0", ¿se ve su código como "git checkout v2.0"? Estoy tratando de renovar mi script de lanzamiento y cuando ejecuto "git checkout v2.0" desde mi máquina de producción, aparece "error: Pathpec 'v2.0' no coincide con ningún archivo conocido por git". A pesar de que he ejecutado, "git push origin --tags" en mi máquina local antes de hacer el "git checkout v2.0" en producción. También he intentado ejecutar "git pull --tags" y "git fetch --tags" en producción antes de llamar a "git checkout v2.0" y eso tampoco funciona ... Todavía estoy obteniendo el error. ¿Algunas ideas?

— John Erck

Estaba a punto de eliminar el comentario anterior, pero luego pensé que mantenerlo podría ayudar a alguien más. Recibí el error porque tenía un TYPO en el nombre de mi etiqueta cuando estaba ejecutando, "git checkout v2.0". Sin embargo, el error relacionado con el error tipográfico es exactamente el mismo error que obtendrá si ejecuta "git checkout v2.0" SIN un error tipográfico ANTES de ejecutar, "git fetch --tags". Entonces, en última instancia, mi problema se resolvió ejecutando "git fetch --tags" ANTES de ejecutar, "git checkout v2.0" sin ningún error tipográfico. ¡Uf!

— John Erck

Bien, sí, debes buscar fetch --tags antes (o git fetch que extraerá todo del control remoto) para que git pueda verificar la etiqueta. Lo siento, acabo de ver tu comentario hoy.

— Khriz

Respuestas:

429

Bien, primero unos pocos términos ligeramente simplificados.

En git, un tag(como muchas otras cosas) es lo que se llama un árbol . Es una forma de referirse a un punto en la historia del proyecto. Los treeishes pueden ser una etiqueta, un commit, un especificador de fecha, un especificador ordinal o muchas otras cosas.

Ahora a branches como una etiqueta pero es móvil. Cuando está "en" una rama y realiza una confirmación, la rama se mueve a la nueva confirmación que hizo, lo que indica su posición actual.

Su HEADes puntero a una rama que se considera "actual". Por lo general, cuando clona un repositorio, HEADseñalará a mastersu vez que apuntará a una confirmación. Cuando haces algo así git checkout experimental, cambias el HEADpunto para apuntar a la experimentalrama que podría apuntar a una confirmación diferente.

Ahora la explicación.

Cuando haces un git checkout v2.0, estás cambiando a un commit al que no apunta a branch. El HEADahora está "separado" y no apunta a una rama. Si decide realizar una confirmación ahora (como puede), no hay un puntero de rama que actualizar para rastrear esta confirmación. Cambiar de nuevo a otra confirmación te hará perder esta nueva confirmación que has hecho. Eso es lo que te dice el mensaje.

Por lo general, lo que puedes hacer es decir git checkout -b v2.0-fixes v2.0. Esto creará un nuevo puntero de rama en la confirmación señalada por el arbolado v2.0(una etiqueta en este caso) y luego cambiará su HEADpunto para apuntar a eso. Ahora, si realiza commits, será posible rastrearlos (usando la v2.0-fixesrama) y puede trabajar como lo haría normalmente. No hay nada "malo" con lo que has hecho, especialmente si solo quieres echar un vistazo al v2.0código. Sin embargo, si desea realizar modificaciones allí de las que desea realizar un seguimiento, necesitará una rama.

Deberías pasar un tiempo entendiendo todo el modelo DAG de git. Es sorprendentemente simple y deja todos los comandos bastante claros.

— Noufal Ibrahim
fuente

Ok, gracias, no necesito hacer ningún cambio en el código, así que creo que está bien. No necesito crear una rama. ¡Muchas gracias!

— Khriz

Me perdí la primera vez que leí esta respuesta, pero después de leer la documentación de ramificación de Git: http://git-scm.com/book/en/Git-Branching-What-a-Branch- ¿ Estaba mucho más claro? .

— Mark Stiles

Impresionante respuesta, pero puedo agregar con respecto a: "Cambiar de nuevo a otra confirmación hará que pierdas esta nueva confirmación que has hecho" git reflog. A menos que haya ocurrido la recolección de basura, es aparentemente "imposible" perder un compromiso.

— Dmitry Minkovsky

Los compromisos no referenciados pueden perderse por una operación de recolección de basura.

— Noufal Ibrahim

La url es incorrecta porque cambiaron el diseño de la página.

— jcubic

Si, es normal. Esto se debe a que comprueba una confirmación única, que no tiene una cabeza. Especialmente (tarde o temprano) no es la cabeza de ninguna rama.

Pero generalmente no hay problema con ese estado. Puede crear una nueva rama de la etiqueta, si esto lo hace sentir más seguro :)

— KingCrunch
fuente

Ok, lo mantendré así ... la seguridad está sobrevalorada de todos modos;)

— Khriz

Como comentaste en la respuesta de Noufals (es la mejor, debo decir;)): Mientras no cambies nada, no hay nada de qué preocuparte. Sin embargo, si asume que puede cambiar algo, simplemente puede crear una rama, porque son baratas en git y puede eliminarla (y volver a crearla más adelante, etc.).

— KingCrunch