Normalmente non risponderei a una domanda che ha già 16 risposte, ma tutte le altre risposte sono sbagliate e la risposta giusta è così semplice. La domanda dice "Esiste un modo semplice per eliminare tutti i rami di monitoraggio il cui equivalente remoto non esiste più?"
Se "semplice" significa cancellarli tutti in una volta, non fragili, non pericolosi e senza fare affidamento su strumenti che non tutti i lettori avranno, allora la risposta giusta è: no.
Alcune risposte sono semplici, ma non fanno ciò che è stato chiesto. Altri fanno ciò che è stato chiesto, ma non sono semplici: tutti fanno affidamento sull'analisi dell'output di Git tramite comandi di manipolazione del testo o linguaggi di script, che potrebbero non essere presenti su tutti i sistemi. Inoltre, la maggior parte dei suggerimenti utilizza comandi di porcellana, il cui output non è progettato per essere analizzato dallo script ("porcellana" si riferisce ai comandi destinati al funzionamento umano; gli script devono utilizzare i comandi "idraulico" di livello inferiore).
Ulteriori letture:
Se vuoi farlo in modo sicuro, per il caso d'uso nella domanda (rami di tracciamento garbage-collection che sono stati eliminati sul server ma esistono ancora come rami locali) e solo con comandi Git di alto livello, devi
git fetch --prune
(o git fetch -p
, che è un alias o git prune remote origin
che fa la stessa cosa senza recuperare, e probabilmente non è quello che vuoi la maggior parte del tempo).
- Nota eventuali rami remoti segnalati come eliminati. Oppure, per trovarli in seguito,
git branch -v
(qualsiasi ramo di tracciamento orfano verrà contrassegnato come "[scomparso]").
git branch -d [branch_name]
su ciascun ramo di tracciamento orfano
(che è quello che propongono alcune delle altre risposte).
Se vuoi scrivere una soluzione, allora for-each-ref
è il tuo punto di partenza, come nella risposta di Mark Longair qui e questa risposta a un'altra domanda , ma non riesco a vedere un modo per sfruttarla senza scrivere un ciclo di script di shell o usare xargs o qualcosa del genere .
Spiegazione di fondo
Per capire cosa sta succedendo, devi apprezzare che, nella situazione del monitoraggio dei rami, non hai un ramo, ma tre. (E ricorda che "branch" significa semplicemente un puntatore a un commit.)
Dato un ramo di tracciamento feature/X
, il repository remoto (server) avrà questo ramo e lo chiamerà feature/X
. Il repository locale ha un ramo remotes/origin/feature/X
che significa "Questo è ciò che il telecomando mi ha detto che la sua caratteristica / ramo X era, l'ultima volta che abbiamo parlato", e infine, il repository locale ha un ramo feature/X
che punta al tuo ultimo commit ed è configurato per "traccia" remotes/origin/feature/X
, nel senso che puoi tirare e spingere per mantenerli allineati.
Ad un certo punto, qualcuno ha eliminato il feature/X
sul telecomando. Da quel momento, rimani con il tuo locale feature/X
(che probabilmente non vuoi più, dal momento che il lavoro sulla funzione X è presumibilmente finito), e il tuo remotes/origin/feature/X
che è certamente inutile perché il suo unico scopo era di ricordare lo stato del ramo del server .
E Git ti consentirà di ripulire automaticamente il ridondante remotes/origin/feature/X
- questo è ciò che git fetch --prune
fa - ma per qualche motivo, non ti consente di eliminare automaticamente i tuoi feature/X
... anche se feature/X
contiene ancora le informazioni di tracciamento orfane, quindi ha le informazioni per identificare ex rami di tracciamento che sono stati completamente uniti. (Dopo tutto, si può dare voi le informazioni che ti permette di fare l'operazione a mano da soli.)
* master
sul mio sistema. Il seguente comando ha funzionato per me:git branch -d $(git branch --merged |tail -n +2)