Au milieu des informations présentées par git help fetch
, il y a ce petit article:
-p, --prune
After fetching, remove any remote-tracking branches which no longer exist on the remote.
Alors, peut-être, git fetch -p
c'est ce que vous cherchez?
EDIT: Ok, pour ceux qui débattent encore de cette réponse 3 ans après les faits, voici un peu plus d'informations sur les raisons pour lesquelles j'ai présenté cette réponse ...
Premièrement, le PO dit vouloir "supprimer également les succursales locales créées à partir de ces succursales distantes [qui ne sont plus sur la télécommande]". Ce n'est pas sans ambiguïté possible en git
. Voici un exemple.
Disons que j'ai un dépôt sur un serveur central et qu'il a deux branches, appelées A
et B
. Si je clone ce dépôt sur mon système local, mon clone aura des références locales (pas encore des branches réelles) appelées origin/A
et origin/B
. Maintenant, disons que je fais ce qui suit:
git checkout -b A origin/A
git checkout -b Z origin/B
git checkout -b C <some hash>
Les faits pertinents ici sont que pour une raison quelconque, j'ai choisi de créer une branche sur mon référentiel local qui a un nom différent de son origine, et j'ai également une branche locale qui n'existe pas (encore) sur le référentiel d'origine.
Maintenant , disons que je supprimer à la fois les A
et les B
branches sur la prise en pension à distance et mettre à jour mon repo local ( git fetch
d' une certaine forme), ce qui provoque mes refs locales origin/A
et origin/B
à disparaître. Maintenant, mon a repo locale trois branches encore, A
, Z
, et C
. Aucun d'entre eux n'a de branche correspondante sur le référentiel distant. Deux d'entre eux ont été "créés à partir de ... branches distantes", mais même si je sais qu'il y avait une branche appelée B
à l'origine, je n'ai aucun moyen de savoir qu'elle a Z
été créée à partir deB
, car il a été renommé dans le processus, probablement pour une bonne raison. Donc, vraiment, sans un processus externe d'enregistrement des métadonnées d'origine de la branche, ou un humain qui connaît l'histoire, il est impossible de dire laquelle des trois branches, le cas échéant, l'OP vise à supprimer. Sans certaines informations externes qui git
ne sont pas automatiquement conservées pour vous, git fetch -p
sont à peu près aussi proches que possible, et toute méthode automatique pour tenter littéralement ce que l'OP a demandé risque de supprimer trop de branches ou de manquer certaines que l'OP aurait autrement veulent supprimer.
Il existe également d'autres scénarios, comme si je crée trois branches distinctes origin/A
pour tester trois approches différentes de quelque chose, puis origin/A
disparaît. Maintenant, j'ai trois branches, qui ne peuvent évidemment pas toutes correspondre au nom, mais elles ont été créées à partir de origin/A
, et donc une interprétation littérale de la question des PO nécessiterait de supprimer les trois. Cependant, cela peut ne pas être souhaitable, si vous pouviez même trouver un moyen fiable de les faire correspondre ...