Lorsque je fais git fetch originet 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 originet 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.
originfourchette: 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 originet similaire à celui git pull --prunementionné 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 branchmontre 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 -psignifie 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--tagsoption. 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'--mirroroption), elles sont également sujettes à l'élagage.
Personnellement, j'aime l'utiliser git fetch origin -p --progresscar 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.