Tra le informazioni presentate da git help fetch
, c'è questo piccolo oggetto:
-p, --prune
After fetching, remove any remote-tracking branches which no longer exist on the remote.
Quindi, forse, git fetch -p
è quello che stai cercando?
EDIT: Ok, per coloro che stanno ancora discutendo questa risposta 3 anni dopo il fatto, ecco alcune informazioni in più sul perché ho presentato questa risposta ...
In primo luogo, l'OP afferma che vogliono "rimuovere anche quei rami locali che sono stati creati da quei rami remoti [che non sono più sul telecomando]". Questo non è inequivocabilmente possibile in git
. Ecco un esempio
Diciamo che ho un repository su un server centrale e ha due rami, chiamato A
e B
. Se clonerò quel repository sul mio sistema locale, il mio clone avrà riferimenti locali (non ancora rami effettivi) chiamati origin/A
e origin/B
. Ora diciamo che faccio quanto segue:
git checkout -b A origin/A
git checkout -b Z origin/B
git checkout -b C <some hash>
I fatti pertinenti qui sono che per qualche ragione ho scelto di creare un ramo sul mio repository locale che ha un nome diverso rispetto alla sua origine, e ho anche un ramo locale che non esiste (ancora) sul repository di origine.
Ora diciamo che posso rimuovere sia l' A
e B
rami sul repo remoto e aggiornare il mio repo locale ( git fetch
di una qualche forma), che fa sì che i miei arbitri locali origin/A
e origin/B
di scomparire. Ora, il mio repo locale ha tre rami ancora, A
, Z
, e C
. Nessuno di questi ha un ramo corrispondente sul repository remoto. Due di loro sono stati "creati da ... rami remoti", ma anche se so che esisteva un ramo chiamato B
sull'origine, non ho modo di sapere che è Z
stato creato daB
, perché è stato rinominato nel processo, probabilmente per una buona ragione. Quindi, davvero, senza alcuni processi esterni che registrano metadati sull'origine dei rami, o un essere umano che conosca la storia, è impossibile dire quale dei tre rami, se ce ne sono, l'OP ha come obiettivo la rimozione. Senza alcune informazioni esterne che git
non vengono conservate automaticamente per te, git fetch -p
è il più vicino possibile e qualsiasi metodo automatico per tentare letteralmente ciò che l'OP ha chiesto corre il rischio di eliminare troppe filiali o di mancarne alcune che altrimenti l'OP vuoi cancellato.
Esistono anche altri scenari, ad esempio se creo tre rami separati origin/A
per testare tre diversi approcci a qualcosa e poi origin/A
scompare. Ora ho tre rami, che ovviamente non possono tutti corrispondere al nome, ma sono stati creati da origin/A
, e quindi un'interpretazione letterale della domanda di OP richiederebbe la rimozione di tutti e tre. Tuttavia, ciò potrebbe non essere desiderabile, se potessi anche trovare un modo affidabile per abbinarli ...