Mit git remote prune origin Ich kann die lokalen Zweige entfernen, die sich nicht mehr auf dem entfernten Rechner befinden.
Ich möchte aber auch lokale Zweige entfernen, die aus diesen entfernten Zweigen erstellt wurden (eine Prüfung, ob sie nicht zusammengeführt sind, wäre schön).
Wie kann ich das tun?
Nach dem Beschneiden können Sie die Liste der entfernten Zweige mit git branch -r . Die Liste der Zweige mit ihrem entfernten Verfolgungszweig kann abgerufen werden mit git branch -vv . Mit Hilfe dieser beiden Listen können Sie also die Zweige der Fernüberwachung finden, die nicht in der Liste der Fernbedienungen enthalten sind.
Mit dieser Zeile sollte es klappen (erfordert bash o zsh , funktioniert nicht mit der Standard-Bourne-Shell):
git fetch -p ; git branch -r | awk '{print $1}' | egrep -v -f /dev/fd/0 <(git branch -vv | grep origin) | awk '{print $1}' | xargs git branch -dDieser String ruft die Liste der entfernten Zweige ab und übergibt sie an egrep über die Standardeingabe. Und filtert die Zweige, die einen entfernten Verfolgungszweig haben (mit git branch -vv und die Filterung für diejenigen, die origin ) und erhält dann die erste Spalte dieser Ausgabe, die der Name der Verzweigung ist. Schließlich werden alle Zweignamen an den Befehl "Zweig löschen" übergeben.
Da es die -d werden keine Zweige gelöscht, die noch nicht mit dem Zweig zusammengeführt wurden, in dem Sie sich zum Zeitpunkt der Ausführung dieses Befehls befinden.
Wenn Sie alle lokalen Zweige löschen wollen, die bereits in Master zusammengeführt wurden, können Sie den folgenden Befehl verwenden:
git branch --merged master | grep -v '^[ *]*master$' | xargs git branch -dWenn Sie Folgendes verwenden main als Ihren Master-Zweig verwenden, sollten Sie den Befehl entsprechend ändern:
git branch --merged main | grep -v '^[ *]*main$' | xargs git branch -d
Inmitten der Informationen, die von git help fetch gibt es diesen kleinen Punkt:
-p, --prune
After fetching, remove any remote-tracking branches which no longer exist on the remote.Also, vielleicht, git fetch -p ist das, wonach Sie suchen?
EDIT: Ok, für diejenigen, die 3 Jahre später immer noch über diese Antwort debattieren, hier ein paar weitere Informationen, warum ich diese Antwort gegeben habe...
Erstens sagt der Auftraggeber, er wolle "auch die lokalen Zweige entfernen, die aus den entfernten Zweigen erstellt wurden [die sich nicht mehr auf dem entfernten Rechner befinden]". Dies ist nicht eindeutig möglich in git . Hier ist ein Beispiel.
Nehmen wir an, ich habe ein Repo auf einem zentralen Server, und es hat zwei Zweige, genannt A y B . Wenn ich dieses Projektarchiv auf mein lokales System klone, hat mein Klon lokale Referenzen (noch keine tatsächlichen Zweige) mit dem Namen origin/A y origin/B . Nehmen wir an, ich tue Folgendes:
git checkout -b A origin/A
git checkout -b Z origin/B
git checkout -b C <some hash>Die relevanten Fakten hier sind, dass ich aus irgendeinem Grund einen Zweig auf meinem lokalen Repository erstellt habe, der einen anderen Namen als sein Ursprung hat, und ich habe auch einen lokalen Zweig, der (noch) nicht auf dem ursprünglichen Repository existiert.
Nehmen wir nun an, ich entferne sowohl die A y B Zweige auf dem entfernten Repo und aktualisieren mein lokales Repo ( git fetch in irgendeiner Form), was dazu führt, dass meine lokalen Refs origin/A y origin/B zu verschwinden. Jetzt hat mein lokales Repo noch drei Zweige, A , Z y C . Keiner dieser Zweige hat einen entsprechenden Zweig auf dem entfernten Repository. Zwei von ihnen wurden "von ... entfernten Zweigen erstellt", aber selbst wenn ich weiß, dass es früher einen Zweig namens B über den Ursprung, kann ich nicht wissen, dass Z wurde erstellt aus B Denn sie wurde im Laufe des Prozesses umbenannt, wahrscheinlich aus einem guten Grund. Ohne einen externen Prozess, der die Metadaten des Zweigursprungs aufzeichnet, oder einen Menschen, der die Historie kennt, ist es also unmöglich zu sagen, welcher der drei Zweige, wenn überhaupt, vom OP zur Entfernung vorgesehen ist. Ohne einige externe Informationen, die git nicht automatisch für Sie pflegen, git fetch -p ist so nahe dran wie möglich, und jede automatische Methode, die buchstäblich versucht, das zu tun, worum der Auftraggeber gebeten hat, birgt das Risiko, entweder zu viele Zweige zu löschen oder einige zu übersehen, die der Auftraggeber eigentlich löschen wollte.
Es gibt auch noch andere Szenarien, z. B. wenn ich drei separate Zweige von origin/A drei verschiedene Ansätze für eine Sache zu testen und dann origin/A geht weg. Jetzt habe ich drei Zweige, die offensichtlich nicht alle vom Namen her übereinstimmen können, aber sie wurden erstellt aus origin/A und daher würde eine wörtliche Auslegung der Frage des Auftraggebers erfordern, alle drei zu entfernen. Das ist jedoch möglicherweise nicht wünschenswert, wenn man überhaupt einen zuverlässigen Weg finden könnte, sie abzugleichen...
Es gibt eine ordentliches npm-Paket das dies für Sie erledigt (und es sollte plattformübergreifend funktionieren).
Installieren Sie es mit: npm install -g git-removed-branches
Und dann git removed-branches zeigt Ihnen alle veralteten lokalen Zweigstellen, und git removed-branches --prune um sie tatsächlich zu löschen.
Dadurch werden die lokalen Zweige gelöscht, für die die entfernten Verfolgungszweige beschnitten wurden. (Stellen Sie sicher, dass Sie sich auf master Zweig!)
git checkout master
git branch -vv | grep ': gone]' | awk '{print $1}' | xargs git branch -dEinzelheiten:
git branch -vv zeigt für lokale Zweige "gone" an, dass der entfernte Zweig beschnitten wurde.
mybranch abc1234 [origin/mybranch: gone] commit comments-d prüft, ob es zusammengeführt wurde ( -D wird es trotzdem löschen)
error: The branch 'mybranch' is not fully merged. CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
