Lorsque je fais git fetch origin
et que l'origine a une branche supprimée, il ne semble pas la mettre à jour dans mon référentiel. Quand je le fais, git branch -r
ça se voit toujours origin/DELETED_BRANCH
.
Comment puis-je réparer cela?
Lorsque je fais git fetch origin
et que l'origine a une branche supprimée, il ne semble pas la mettre à jour dans mon référentiel. Quand je le fais, git branch -r
ça se voit toujours origin/DELETED_BRANCH
.
Comment puis-je réparer cela?
Réponses:
Vous devez faire ce qui suit
git fetch -p
Cela mettra à jour la base de données locale des succursales distantes.
origin
fourchette: git fetch -p origin
quand j'ai fait alors git branch -r
la branche distante inexistante ne s'est plus affichée.
git remote prune origin
et similaire à celui git pull --prune
mentionné sur stackoverflow.com/a/6127884/94687 et stackoverflow.com/a/17983126/94687 respectivement.
[deleted] (none) -> origin/ < branch name >
et la branche est toujours montrée sur le repo local une idée pourquoi?
git branch
montre toujours les branches qui auraient été supprimées.
Sur http://www.gitguys.com/topics/adding-and-removing-remote-branches/
Une fois que quelqu'un a supprimé une branche d'un référentiel distant, git ne supprimera pas automatiquement les branches du référentiel local lorsqu'un utilisateur effectue un git pull ou git fetch. Cependant, si l'utilisateur souhaite que toutes les branches de suivi soient supprimées de son référentiel local qui ont été supprimées dans un référentiel distant, il peut taper:
git remote prune origin
Remarque: le paramètre -p de git fetch -p
signifie en fait "prune".
Dans les deux cas, les branches distantes non existantes seront supprimées de votre référentiel local.
Vous devez faire ce qui suit
git fetch -p
afin de synchroniser votre liste de succursales. Le manuel de git dit
-p
,--prune
Après l'extraction, supprimez toutes les références de suivi à distance qui n'existent plus sur la télécommande. Les balises ne sont pas soumises à l'élagage si elles sont extraites uniquement en raison du suivi automatique des balises par défaut ou en raison d'une--tags
option. Cependant, si les balises sont extraites en raison d'une refspec explicite (sur la ligne de commande ou dans la configuration à distance, par exemple si la télécommande a été clonée avec l'--mirror
option), elles sont également sujettes à l'élagage.
Personnellement, j'aime l'utiliser git fetch origin -p --progress
car il affiche un indicateur de progression.
Concernant git fetch -p
, son comportement a changé dans Git 1.9, et seul Git 2.9.x / 2.10 le reflète.
Voir commit 9e70233 (13 juin 2016) de Jeff King ( peff
) .
(Fusionné par Junio C Hamano - gitster
- dans commit 1c22105 , 6 juil.2016 )
fetch
: documenter que l'élagage a lieu avant la récupérationCela a été changé dans 10a6cc8 (
fetch --prune
: Run prune before fetching, 2014-01-02), mais il semble que personne dans cette discussion ne se soit rendu compte que nous faisions de la publicité pour l '"après" explicitement.
La documentation indique donc maintenant:
Avant la récupération, supprimez toutes les références de suivi à distance qui n'existent plus sur la télécommande
C'est parce que:
Lorsque nous avons une branche de suivi à distance nommée "
frotz/nitfol
" à partir d'une extraction précédente et que l'amont a maintenant une branche nommée "frotz
", l'extraction échouera à supprimer "frotz/nitfol
" avec un "git fetch --prune
" de l'amont. git informerait l'utilisateur d'utiliser "git remote prune
" pour résoudre le problème.Modifiez le mode de fonctionnement de "
fetch --prune
" en déplaçant l'opération d'élagage avant l'opération de récupération. De cette façon, au lieu d'avertir l'utilisateur d'un conflit, il le corrige automatiquement.