Normalerweise würde ich eine Frage mit 16 Antworten nicht beantworten, aber alle anderen Antworten sind falsch und die richtige Antwort ist so einfach. Die Frage lautet: "Gibt es eine einfache Möglichkeit, alle Tracking-Zweige zu löschen, deren Remote-Äquivalent nicht mehr vorhanden ist?"
Wenn "einfach" bedeutet, alle auf einmal zu löschen, nicht zerbrechlich, nicht gefährlich und ohne Vertrauen auf Tools, die nicht alle Leser haben, lautet die richtige Antwort: Nein.
Einige Antworten sind einfach, aber sie tun nicht das, was gefragt wurde. Andere tun, was gefragt wurde, sind aber nicht einfach: Alle verlassen sich darauf, die Git-Ausgabe über Textmanipulationsbefehle oder Skriptsprachen zu analysieren, die möglicherweise nicht auf jedem System vorhanden sind. Darüber hinaus verwenden die meisten Vorschläge Porzellanbefehle, deren Ausgabe nicht für die Analyse durch Skripte vorgesehen ist ("Porzellan" bezieht sich auf Befehle, die für den menschlichen Betrieb bestimmt sind; Skripte sollten die untergeordneten Befehle "Sanitär" verwenden).
Weiterführende Literatur:
Wenn Sie dies sicher tun möchten, müssen Sie für den Anwendungsfall in der Frage (Garbage-Collect-Tracking-Zweige, die auf dem Server gelöscht wurden, aber noch als lokale Zweige vorhanden sind) und nur Git-Befehle auf hoher Ebene verwenden
git fetch --prune
(oder git fetch -p
, was ein Alias ist oder git prune remote origin
was dasselbe tut, ohne es abzurufen, und wahrscheinlich nicht das ist, was Sie die meiste Zeit wollen).
- Beachten Sie alle Remote-Zweige, die als gelöscht gemeldet werden. Oder, um sie später zu finden
git branch -v
(jeder verwaiste Verfolgungszweig wird mit "[weg]" markiert).
git branch -d [branch_name]
auf jedem verwaisten Tracking-Zweig
(was einige der anderen Antworten vorschlagen).
Wenn Sie eine Lösung skripten möchten, for-each-ref
ist dies Ihr Ausgangspunkt, wie in Mark Longairs Antwort hier und dieser Antwort auf eine andere Frage , aber ich sehe keine Möglichkeit, sie auszunutzen, ohne eine Shell-Skriptschleife zu schreiben oder xargs oder ähnliches zu verwenden .
Hintergrunderklärung
Um zu verstehen, was passiert, müssen Sie wissen, dass Sie in der Situation der Nachverfolgung von Zweigen nicht einen Zweig haben, sondern drei. (Und denken Sie daran, dass "Verzweigung" einfach einen Zeiger auf ein Commit bedeutet.)
Bei einem Tracking-Zweig feature/X
verfügt das Remote-Repository (Server) über diesen Zweig und ruft ihn auf feature/X
. Ihr lokales Repository verfügt über einen Zweig, remotes/origin/feature/X
der bedeutet: "Dies hat mir die Fernbedienung mitgeteilt, dass der Feature- / X-Zweig das letzte Mal war, als wir gesprochen haben". Schließlich verfügt das lokale Repository über einen Zweig, feature/X
der auf Ihr letztes Commit verweist und für den konfiguriert ist "Spur" remotes/origin/feature/X
, was bedeutet, dass Sie ziehen und drücken können, um sie ausgerichtet zu halten.
Irgendwann hat jemand das feature/X
auf der Fernbedienung gelöscht . Von diesem Moment an bleiben Sie bei Ihrem lokalen feature/X
(was Sie wahrscheinlich nicht mehr wollen, da die Arbeit an Feature X vermutlich abgeschlossen ist) und Ihrem, remotes/origin/feature/X
was sicherlich nutzlos ist, weil sein einziger Zweck darin bestand, sich den Status des Serverzweigs zu merken .
Und Git lässt Sie die Redundanz automatisch bereinigen remotes/origin/feature/X
- das ist es, was es git fetch --prune
tut - aber aus irgendeinem Grund können Sie Ihre eigenen nicht automatisch löschen feature/X
... obwohl Ihre feature/X
noch die verwaisten Tracking-Informationen enthält, so dass sie die Informationen enthalten um frühere Tracking-Zweige zu identifizieren, die vollständig zusammengeführt wurden. (Schließlich können Sie die Informationen erhalten, mit denen Sie die Operation von Hand selbst durchführen können.)
* master
auf meinem System. Der folgende Befehl hat bei mir funktioniert:git branch -d $(git branch --merged |tail -n +2)