remove - git tag commit id
El error "etiqueta ya existe en el control remoto" después de volver a crear la etiqueta git (7)
Aparece el siguiente error después de ejecutar los siguientes pasos:
To [email protected]:username/repo-name.git
! [rejected] dev -> dev (already exists)
error: failed to push some refs to ''[email protected]:username/repo-name.git''
hint: Updates were rejected because the tag already exists in the remote.
- Creado el repositorio
- Clonado el repositorio en la máquina local.
- Modificó el archivo README, confirmó los cambios y presionó la confirmación.
- Creado tag
dev:git tag dev - Etiquetas
git push --tags:git push --tags - Modificó el archivo README, confirmó los cambios y presionó la confirmación.
Eliminado tag
dev, lo creó de nuevo y presionó etiquetas:git tag -d dev git tag dev git push --tags
¿Por qué está pasando esto?
Estoy en Mac. Mis amigos que usan Linux (Ubuntu) no tienen este problema. Sé que puedo usar git push --tags -f para forzar la actualización de la etiqueta, pero esto es peligroso (por ejemplo, reescribir una confirmación hecha por error solo en la etiqueta, no en la rama).
Editar, 24 de noviembre de 2016: esta respuesta es aparentemente popular, así que estoy agregando una nota aquí. Si reemplaza una etiqueta en un servidor central, cualquiera que tenga la etiqueta anterior -cualquier clon del repositorio del servidor central que ya tenga la etiqueta- podría conservar su etiqueta anterior . Entonces, mientras esto le dice cómo hacerlo, esté realmente seguro de que quiere hacerlo. Necesitará que todos los que ya tienen la etiqueta "incorrecta" eliminen su "etiqueta incorrecta" y la reemplacen con la nueva "etiqueta correcta".
Las pruebas en Git 2.10 / 2.11 muestran que conservar la etiqueta anterior es el comportamiento predeterminado para los clientes que ejecutan git fetch , y la actualización es el comportamiento predeterminado para los clientes que ejecutan git fetch --tags .
(Sigue la respuesta original)
Cuando solicite insertar etiquetas, git push --tags envía (junto con cualquier confirmación y otros objetos necesarios y cualquier otra actualización ref desde la configuración de inserción) a la solicitud de actualización remota del formulario new-sha1 refs/tags/ name . (Bueno, envía sin embargo muchos: uno de esos para cada etiqueta).
La solicitud de actualización es modificada por el control remoto para agregar una old-sha1 (o de nuevo, una para cada etiqueta), luego entregada a los ganchos de pre-recepción y / o actualización (cualesquiera ganchos que existan en el control remoto). Esos ganchos pueden decidir si permiten o rechazan la etiqueta crear / eliminar / actualizar.
El valor old-sha1 es el SHA-1 "nulo" de todos los ceros si se está creando la etiqueta. El new-sha1 es el SHA-1 nulo si la etiqueta se está eliminando. De lo contrario, ambos valores de SHA-1 son valores reales y válidos.
Incluso sin ganchos, hay una especie de "gancho incorporado" que también se ejecuta: el control remoto se negará a mover una etiqueta a menos que use la bandera de "fuerza" (aunque el "gancho integrado" siempre está bien con ambos "agregar" y "eliminar"). El mensaje de rechazo que está viendo proviene de este gancho integrado. (Por cierto, este mismo gancho integrado también rechaza actualizaciones de sucursales que no son de avance rápido). 1
Pero, aquí está una de las claves para entender lo que está pasando, el paso de git push no tiene idea de si el control remoto tiene esa etiqueta ahora, y si es así, qué valor de SHA-1 tiene. Solo dice "aquí está mi lista completa de etiquetas, junto con sus valores SHA-1". El control remoto compara los valores y si hay adiciones y / o cambios, ejecuta los ganchos en esos. (Para las etiquetas que son iguales, no hace nada. Para las etiquetas que no tiene, lo que hace, ¡tampoco hace nada!)
Si elimina la etiqueta localmente, luego push , su inserción simplemente no transfiere la etiqueta. El control remoto asume que no se debe hacer ningún cambio.
Si elimina la etiqueta localmente, luego creela apuntando a un lugar nuevo, luego push , su inserción transfiere la etiqueta, y el control remoto ve esto como un cambio de etiqueta y rechaza el cambio, a menos que sea un empuje forzado.
Por lo tanto, tienes dos opciones:
- hacer un empuje de fuerza, o
- eliminar la etiqueta en el control remoto.
Esto último es posible a través de git push 2 aunque borrar la etiqueta localmente y push ing no tenga ningún efecto. Suponiendo que el nombre del control remoto es origin , y la etiqueta que desea eliminar es dev :
git push origin :refs/tags/dev
Esto le pide al control remoto que elimine la etiqueta. La presencia o ausencia del revelador de etiqueta en su repositorio local es irrelevante; este tipo de push , con : remoteref como un refspec, es un push de eliminación pura.
El control remoto puede o no permitir la eliminación de etiquetas (dependiendo de los ganchos añadidos adicionales). Si permite la eliminación, la etiqueta desaparecerá y una segunda git push --tags , cuando tenga una etiqueta de desarrollo local que apunte a algún compromiso o un objeto de repo de etiqueta anotado, envíe su nueva etiqueta de desarrollo. En el control remoto, dev ahora será una etiqueta recién creada, por lo que es probable que el control remoto permita el empuje (de nuevo, esto depende de los ganchos añadidos).
El empuje de fuerza es más simple. Si quiere asegurarse de no actualizar nada más que la etiqueta, simplemente dígale a git push que envíe solo ese refspec:
git push --force origin refs/tags/dev:refs/tags/dev
(Nota: no necesita --tags si está presionando explícitamente solo una etiqueta ref-spec).
1 Por supuesto, la razón de este gancho integrado es ayudar a reforzar el comportamiento que otros usuarios de ese mismo repositorio remoto esperan: que las ramas no se rebobinan y las etiquetas no se mueven. Si fuerza el push, debe informar a los otros usuarios que está haciendo esto para que puedan corregirlo. Tenga en cuenta que Git 1.8.2 recientemente aplica las "etiquetas no se mueven para nada". las versiones anteriores permitirían que la etiqueta "avanzara" en el gráfico de confirmación, al igual que los nombres de las ramas. Ver las notas de la versión de git 1.8.2 .
2 Es trivial si puede iniciar sesión en el control remoto. Simplemente ve al repositorio de Git allí y ejecuta la git tag -d dev . Tenga en cuenta que, en cualquier caso, borrar la etiqueta en el control remoto o usar git push para eliminarla, hay un período de tiempo en el que cualquiera que acceda al control remoto encontrará que falta la etiqueta dev . (Continuarán teniendo su propia etiqueta anterior, si es que ya la tienen, e incluso podrían volver a colocar su vieja etiqueta antes de que puedas presionar la nueva).
Es bastante simple si usa Source Tree .
Básicamente, solo necesita eliminar y volver a agregar la etiqueta conflictiva:
- Ir a la pestaña Repositorio -> Etiqueta -> Eliminar etiqueta
- Seleccione el nombre de la etiqueta conflictiva
- Marque Eliminar etiqueta de todos los controles remotos
- Presione Eliminar
- Crea una nueva etiqueta con el mismo nombre para la confirmación correcta
- Asegúrese de marcar Push all tags cuando empuje sus cambios a control remoto
La razón por la que te rechazan es porque tu etiqueta perdió sincronización con la versión remota. Este es el mismo comportamiento con las ramas.
sincronizar con la etiqueta desde el control remoto mediante git pull --rebase <repo_url> +refs/tags/<TAG> y después de la sincronización, debe gestionar los conflictos . Si tienes un diftool instalado (por ejemplo, git mergetool meld ) git mergetool meld para sincronizar el control remoto y guarda tus cambios.
La razón por la que está tirando con --rebase flag es que quiere poner su trabajo encima del control remoto para evitar otros conflictos.
Además, lo que no entiendo es ¿por qué eliminarías la etiqueta dev y la volverías a crear? Las etiquetas se utilizan para especificar versiones de software o hitos. Ejemplo de etiquetas git v0.1dev , v0.0.1alpha , v2.3-cr (cr - versión candidata) y así sucesivamente ..
Otra forma de resolverlo es emitir un git reflog e ir al momento en que presionó la etiqueta dev en el control remoto. Copie la identificación del commit y git reset --mixed <commmit_id_from_reflog> esta manera usted sabrá que su etiqueta estaba sincronizada con el control remoto en el momento en que la presionó y no surgirán conflictos.
Parece que llegué tarde a este problema y ya se me respondió, pero lo que podría hacerse es: (en mi caso, solo tenía una etiqueta localmente, así que ... eliminé la etiqueta anterior y la retiré con :
git tag -d v1.0
git tag -a v1.0 -m "My commit message"
Entonces:
git push --tags -f
Eso actualizará todas las etiquetas en el control remoto.
¡Podría ser peligroso! Usar bajo su propio riesgo.
Si desea ACTUALIZAR una etiqueta, digamos que 1.0.0
-
git checkout 1.0.0 - hacer tus cambios
-
git ci -am ''modify some content'' -
git tag -f 1.0.0 - eliminar la etiqueta remota en github:
git push origin --delete 1.0.0 -
git push origin 1.0.0
HECHO