La comprobación de la label de Git conduce al "estado HEAD aislado"

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

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

Y he llevado esta label al repository remoto

 git push --tags 

Cuando bash ejecutar la secuencia de commands de implementación y verificar la label v2.0 recibo este post:

Estás en el estado 'HEAD separado'. Puede mirar alnetworkingedor, realizar cambios experimentales y confirmarlos, y puede descartar cualquier compromiso que realice en este estado sin afectar a ninguna de las twigs realizando otro pago. Si desea crear una nueva bifurcación para retener las confirmaciones que crea, puede hacerlo (ahora o más adelante) utilizando -b con el command de finalización nuevamente. Ejemplo: git checkout -b new_branch_name HEAD está ahora en

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

 git branch 

Obtengo esta salida:

 * (no branch) master 

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

De acuerdo, primero algunos términos ligeramente simplificados.

En git , una tag (como muchas otras cosas) es lo que se conoce como treeish . Es una forma de referirse a un punto en la historia del proyecto. Treeishes puede ser una label, una confirmación, un especificador de date, un especificador ordinal u otras muchas cosas.

Ahora una branch es como una label, pero es movible. Cuando estás "en" una twig y haces una confirmación, la twig se mueve al nuevo compromiso que hiciste indicando su position actual.

Su HEAD es un puntero a una twig que se considera "actual". Por lo general, al clonar un repository, HEAD apuntará a master que a su vez apuntará a un compromiso. Cuando luego haces algo como git checkout experimental , cambias el HEAD para apuntar a la twig experimental que podría apuntar a un commit diferente.

Ahora la explicación.

Cuando haces un git checkout v2.0 , estás cambiando a un commit que no está señalado por una branch . El HEAD ahora está "separado" y no apunta a una twig. Si decide hacer un commit ahora (como puede ser), no hay un puntero de twig para actualizar para rastrear este commit. El cambio a otra confirmación te hará perder este nuevo compromiso que has realizado. Eso es lo que el post te está diciendo.

Generalmente, lo que puedes hacer es decir git checkout -b v2.0-fixes v2.0 . Esto creará un nuevo puntero de bifurcación en la confirmación apuntada por treeish v2.0 (una label en este caso) y luego cambia tu HEAD para que apunte a eso. Ahora, si realiza commits, será posible rastrearlos (usando la twig v2.0-fixes ) y podrá trabajar como lo haría normalmente. No hay nada "incorrecto" en lo que has hecho especialmente si solo quieres echarle un vistazo al código v2.0 . Sin embargo, si desea realizar alguna modificación de la que desea realizar un seguimiento, necesitará una sucursal.

Deberías pasar algún time comprendiendo todo el model DAG de git. Es sorprendentemente simple y hace todos los commands bastante claros.

Sí, es normal. Esto se debe a que pagas una única comisión, eso no tiene una ventaja. Especialmente es (tarde o temprano) no es cabeza de ninguna twig.

Pero generalmente no hay problema con ese estado. Puedes crear una nueva twig desde la label, si esto te hace sentir más seguro 🙂