Cuando lo hago git fetch originy el origen tiene una rama eliminada, no parece actualizarla en mi repositorio. Cuando lo hago git branch -r, todavía se nota origin/DELETED_BRANCH.
¿Cómo puedo arreglar esto?
Respuestas:
Necesitas hacer lo siguiente
git fetch -p
Esto actualizará la base de datos local de sucursales remotas.
originbifurcación: git fetch -p origin cuando lo hice, git branch -r la rama remota inexistente ya no apareció.
git remote prune originy similar al git pull --prunemencionado en stackoverflow.com/a/6127884/94687 y stackoverflow.com/a/17983126/94687 respectivamente.
[deleted] (none) -> origin/ < branch name >y la rama todavía se muestra en el repositorio local alguna idea de por qué?
git branchaún muestra las ramas que supuestamente se eliminaron.
Desde http://www.gitguys.com/topics/adding-and-removing-remote-branches/
Después de que alguien elimine una rama de un repositorio remoto, git no eliminará automáticamente las ramas del repositorio local cuando un usuario haga un git pull o git fetch. Sin embargo, si el usuario desea que se eliminen todas las ramas de seguimiento de su repositorio local que se han eliminado en un repositorio remoto, pueden escribir:
origen de ciruela remota git
Como nota, el parámetro -p de en git fetch -prealidad significa "podar".
De cualquier forma que elija, las ramas remotas no existentes se eliminarán de su repositorio local.
Necesitas hacer lo siguiente
git fetch -p
para sincronizar su lista de sucursales. El manual de git dice
-p,--prune
Después de buscar, elimine cualquier referencia de seguimiento remoto que ya no exista en el control remoto. Las etiquetas no están sujetas a poda si se obtienen solo debido al seguimiento automático de etiquetas predeterminado o debido a una--tagsopción. Sin embargo, si las etiquetas se obtienen debido a una especificación de referencia explícita (ya sea en la línea de comando o en la configuración remota, por ejemplo, si el control remoto se clonó con la--mirroropción), también están sujetas a poda.
Personalmente me gusta usar git fetch origin -p --progressporque muestra un indicador de progreso.
En cuanto a git fetch -p, su comportamiento cambió en Git 1.9, y solo Git 2.9.x / 2.10 refleja eso.
Ver commit 9e70233 (13 de junio de 2016) por Jeff King ( peff) .
(Fusionada por Junio C Hamano - gitster- en commit 1c22105 , 06 jul 2016)
fetch: documenta que la poda ocurre antes de ir a buscarEsto cambió en 10a6cc8 (
fetch --prune: Ejecutar podar antes de ir a buscar, 2014-01-02), pero parece que nadie en esa discusión se dio cuenta de que estábamos anunciando el "después" explícitamente.
Entonces la documentación ahora dice:
Antes de buscar, elimine cualquier referencia de seguimiento remoto que ya no exista en el control remoto
Eso es porque:
Cuando tenemos una rama de seguimiento remoto llamada "
frotz/nitfol" de una recuperación anterior, y el flujo ascendente ahora tiene una rama llamada "frotz", la recuperación fallará al eliminar "frotz/nitfol" con un "git fetch --prune" del flujo ascendente. git informaría al usuario que use "git remote prune" para solucionar el problema.Cambie la forma en que "
fetch --prune" funciona moviendo la operación de poda antes de la operación de recuperación. De esta manera, en lugar de advertir al usuario de un conflicto, lo corrige automáticamente.