¿buscar desde el origen con ramas remotas eliminadas?
440
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.
muchas gracias. Eliminé manualmente esas ramas antes.
Maksim Dmitriev
44
Por alguna razón, su comando no funcionó, pero este sí lo hizo para una rama remota inexistente en mi originbifurcación: git fetch -p origin cuando lo hice, git branch -r la rama remota inexistente ya no apareció.
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.
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.
fetch: documenta que la poda ocurre antes de ir a buscar
Esto 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.
Respuestas:
Necesitas hacer lo siguiente
Esto actualizará la base de datos local de sucursales remotas.
fuente
origin
bifurcación:git fetch -p origin
cuando lo hice,git branch -r
la rama remota inexistente ya no apareció.git remote prune origin
y similar algit pull --prune
mencionado 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 branch
aún muestra las ramas que supuestamente se eliminaron.Desde http://www.gitguys.com/topics/adding-and-removing-remote-branches/
Como nota, el parámetro -p de en
git fetch -p
realidad significa "podar".De cualquier forma que elija, las ramas remotas no existentes se eliminarán de su repositorio local.
fuente
Necesitas hacer lo siguiente
para sincronizar su lista de sucursales. El manual de git dice
Personalmente me gusta usar
git fetch origin -p --progress
porque muestra un indicador de progreso.fuente
Esto funcionó para mí.
fuente
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)Entonces la documentación ahora dice:
Eso es porque:
fuente