in

¿Qué es la etiqueta git, cómo crear etiquetas y cómo pagar las etiquetas remotas de git?

apple touch icon@2

(Esta respuesta tomó un tiempo para escribir, y la respuesta de codeWizard es correcta en su objetivo y esencia, pero no del todo completa, así que publicaré esto de todos modos).


No existe una «etiqueta Git remota». Solo hay «etiquetas». Señalo todo esto para no ser pedante,1 pero debido a que hay mucha confusión sobre esto con los usuarios casuales de Git, y la documentación de Git no es muy útil2 para principiantes. (No está claro si la confusión se debe a una documentación deficiente, o la documentación deficiente se debe a que esto es inherentemente algo confuso, o qué).

Allí están «sucursales remotas», más propiamente llamadas «sucursales de seguimiento remoto», pero vale la pena señalar que en realidad son entidades locales. Sin embargo, no hay etiquetas remotas (a menos que las (re) invente). Solo hay etiquetas locales, por lo que debe obtener la etiqueta localmente para poder usarla.

La forma general de nombres para confirmaciones específicas, que Git llama referencias—Es cualquier cadena que comience con refs/. Una cadena que comienza con refs/heads/ nombra una rama; una cadena que comienza con refs/remotes/ nombra una rama de seguimiento remoto; y una cadena que comienza con refs/tags/ nombra una etiqueta. El nombre refs/stash es la referencia de alijo (como lo usa git stash; tenga en cuenta la falta de una barra inclinada al final).

Hay algunos nombres de casos especiales inusuales que no comienzan con refs/: HEAD, ORIG_HEAD, MERGE_HEAD, y CHERRY_PICK_HEAD en particular son todos también nombres que pueden referirse a confirmaciones específicas (aunque HEAD normalmente contiene el nombre de una rama, es decir, contiene ref: refs/heads/branch). Pero, en general, las referencias comienzan con refs/.

Una cosa que hace Git para que esto sea confuso es que le permite omitir el refs/, y a menudo la palabra después refs/. Por ejemplo, puede omitir refs/heads/ o refs/tags/ cuando se refiere a una sucursal o etiqueta local, y de hecho, debe omitir refs/heads/ al consultar una sucursal local! Puede hacer esto siempre que el resultado sea inequívoco o, como acabamos de señalar, cuando deba hacerlo (por git checkout branch).

Es cierto que las referencias existen no solo en su propio repositorio, sino también en repositorios remotos. Sin embargo, Git le da acceso a las referencias de un repositorio remoto solo en momentos muy específicos: es decir, durante fetch y push operaciones. También puedes usar git ls-remote o git remote show para verlos, pero fetch y push son los puntos de contacto más interesantes.

Refspecs

Durante fetch y push, Git usa las cadenas que llama refspecs para transferir referencias entre el repositorio local y remoto. Por lo tanto, es en estos momentos, y a través de refspecs, que dos repositorios de Git pueden sincronizarse entre sí. Una vez que sus nombres estén sincronizados, puede usar el mismo nombre que usa alguien con el control remoto. Hay algo de magia especial aquí en fetch, sin embargo, afecta tanto a los nombres de las ramas como a los de las etiquetas.

Deberías pensar en git fetch como indicarle a su Git que llame (o tal vez envíe un mensaje de texto) a otro Git, el «remoto», y tenga una conversación con él. Al principio de esta conversación, el control remoto enumera todas sus referencias: todo en refs/heads/ y todo en refs/tags/, junto con cualquier otra referencia que tenga. Su Git escanea a través de estos y (según la especificación de referencia de búsqueda habitual) renombra sus ramas.

Echemos un vistazo a la especificación de referencia normal para el control remoto llamado origin:

$ git config --get-all remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
$ 

Esta especificación de referencia le indica a su Git que tome todas las coincidencias de nombres refs/heads/*—Es decir, cada rama del control remoto— y cambia su nombre a refs/remotes/origin/*, es decir, mantenga la parte coincidente igual, cambiando el nombre de la rama (refs/heads/) a un nombre de rama de seguimiento remoto (refs/remotes/, específicamente, refs/remotes/origin/).

Está a través de esta refspec ese originLas sucursales se convierten en sus sucursales de seguimiento remoto para origin. El nombre de la sucursal se convierte en el nombre de la sucursal de seguimiento remoto, con el nombre del control remoto, en este caso origin, incluido. El signo mas + en la parte delantera de refspec establece el indicador «force», es decir, su rama de seguimiento remoto se actualizará para que coincida con el nombre de la rama remota, independientemente de lo que se necesite para hacerla coincidir. (Sin el +, las actualizaciones de rama se limitan a cambios de «avance rápido», y las actualizaciones de etiquetas simplemente se ignoran desde la versión 1.8.2 de Git más o menos; antes se aplicaban las mismas reglas de avance rápido).

Etiquetas

Pero, ¿qué pasa con las etiquetas? No hay refspec para ellos, al menos, no de forma predeterminada. Puede establecer uno, en cuyo caso la forma de refspec depende de usted; o puedes correr git fetch --tags. Utilizando --tags tiene el efecto de agregar refs/tags/*:refs/tags/* a la refspec, es decir, trae todas las etiquetas (pero no actualiza tu etiqueta si ya tiene una etiqueta con ese nombre, independientemente de lo que diga la etiqueta del control remoto Editar, enero de 2017: a partir de Git 2.10, las pruebas muestran que --tags actualiza a la fuerza sus etiquetas desde las etiquetas del control remoto, como si la refspec leyera +refs/tags/*:refs/tags/*; esto puede ser una diferencia en el comportamiento de una versión anterior de Git).

Tenga en cuenta que no hay cambio de nombre aquí: si es remoto origin tiene etiqueta xyzzyy tu no, y tu git fetch origin "refs/tags/*:refs/tags/*", usted obtiene refs/tags/xyzzy agregado a su repositorio (apuntando a la misma confirmación que en el control remoto). Si utiliza +refs/tags/*:refs/tags/* entonces tu etiqueta xyzzy, si tienes uno, es reemplazado por el de origin. Eso es el + force flag en una refspec significa «reemplazar el valor de mi referencia con el que mi Git obtiene de su Git».

Etiquetas automáticas durante la recuperación

Por razones históricas,3 si no usa ni el --tags opción ni la --no-tags opción, git fetch toma una acción especial. Recuerde que dijimos anteriormente que el control remoto comienza mostrándose en su Git local todos de sus referencias, ya sea que su Git local quiera verlas o no.4 Su Git toma nota de todas las etiquetas que ve en este punto. Luego, cuando comience a descargar cualquier objeto de confirmación que necesite para manejar lo que sea que esté obteniendo, si una de esas confirmaciones tiene el mismo ID que cualquiera de esas etiquetas, git agregará esa etiqueta, o esas etiquetas, si varias etiquetas tienen ese ID, a su repositorio.

Editar, enero de 2017: las pruebas muestran que el comportamiento en Git 2.10 es ahora: Si su Git proporciona una etiqueta llamada T, y no tienes una etiqueta llamada T, y el ID de confirmación asociado con T es un antepasado de una de sus ramas que tu git fetch está examinando, tu Git agrega T a tus etiquetas con o sin --tags. Añadiendo --tags hace que su Git obtenga todos sus etiquetas y también forzar la actualización.

Línea de fondo

Puede que tengas que usar git fetch --tags para obtener sus etiquetas. Si los nombres de sus etiquetas entran en conflicto con los nombres de sus etiquetas existentes, mayo (dependiendo de la versión de Git) incluso tiene que eliminar (o cambiar el nombre) algunas de sus etiquetas, y luego ejecutar git fetch --tags, para obtener sus etiquetas. Dado que las etiquetas, a diferencia de las sucursales remotas, no tienen un cambio de nombre automático, los nombres de las etiquetas deben coincidir con sus nombres de etiqueta, por lo que puede tener problemas con los conflictos.

En la mayoría casos normales, sin embargo, un simple git fetch hará el trabajo, trayendo sus confirmaciones y sus etiquetas coincidentes, y dado que ellos, sean quienes sean, etiquetarán las confirmaciones en el momento en que publican esas confirmaciones, usted se mantendrá al día con sus etiquetas. Si no crea sus propias etiquetas, ni mezcla su repositorio y otros repositorios (a través de varios controles remotos), tampoco tendrá colisiones de nombres de etiquetas, por lo que no tendrá que preocuparse por eliminar o cambiar el nombre de las etiquetas para poder obtener sus etiquetas.

Cuando necesitas nombres calificados

Mencioné anteriormente que puedes omitir refs/ casi siempre, y refs/heads/ y refs/tags/ y así sucesivamente la mayor parte del tiempo. Pero cuando hipocresía ¿usted?

La respuesta completa (o casi completa de todos modos) está en los gitrevisions documentación. Git resolverá un nombre en un ID de confirmación utilizando la secuencia de seis pasos que se proporciona en el enlace. Curiosamente, las etiquetas anulan las ramas: si hay una etiqueta xyzzy y una rama xyzzy, y apuntan a diferentes confirmaciones, entonces:

git rev-parse xyzzy

le dará el ID al que apunta la etiqueta. Sin embargo, y esto es lo que falta en gitrevisionsgit checkout prefiere nombres de sucursales, por lo que git checkout xyzzy te pondrá en la rama, sin tener en cuenta la etiqueta.

En caso de ambigüedad, casi siempre puede deletrear el nombre de la referencia usando su nombre completo, refs/heads/xyzzy o refs/tags/xyzzy. (Tenga en cuenta que esto lo hace trabajar con git checkout, pero de una manera quizás inesperada: git checkout refs/heads/xyzzy provoca un pago de HEAD separado en lugar de un pago de sucursal. Es por eso que solo debes tener en cuenta que git checkout primero usará el nombre corto como nombre de la sucursal: así es como verifica la sucursal xyzzy incluso si la etiqueta xyzzy existe. Si desea ver la etiqueta, puede usar refs/tags/xyzzy.)

Porque como gitrevisions notas) Git intentará refs/name, también puedes simplemente escribir tags/xyzzy para identificar el compromiso etiquetado xyzzy. (Si alguien ha logrado escribir una referencia válida llamada xyzzy dentro $GIT_DIR, sin embargo, esto se resolverá como $GIT_DIR/xyzzy. Pero normalmente solo los diversos *HEAD los nombres deben estar en $GIT_DIR.)


1Está bien, está bien, «no solo ser pedante «. 🙂

2Algunos dirían «muy poco útil», y yo tendería a estar de acuerdo, en realidad.

3Básicamente, git fetch, y todo el concepto de controles remotos y especificaciones de referencia, fue una adición tardía a Git, que sucedió en la época de Git 1.5. Antes de eso, solo había algunos casos especiales ad-hoc, y la búsqueda de etiquetas era uno de ellos, por lo que se incorporó a través de un código especial.

4Si ayuda, piense en el Git remoto como un Destellador, en el significado de la jerga.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

pyqt

Tutorial de PyQt

7xEVUjcX2tGcoP7SzYvVUQ 1200 80

Arma Maravilla de Firebase Z | GamesRadar +