Mit git fetch --prune werden lokale Remote-Tracking-Zweige gelöscht, wenn die Verzweigung auf dem Remote-Computer gelöscht wurde. Setzen Sie remote.origin.prune unter Verwendung des folgenden ... auf
%Vor%... macht die Verwendung des Befehls fetch immer implizit die Option --prune.
Ich stelle für einige Entwickler in meiner Gruppe eine Best Practices / Einführung in git zusammen, die damit nicht vertraut sind. Ich möchte sicher sein, dass ich weiß, dass dies kein gefährliches Verhalten ist, bevor ich es ihnen rate. Ich gebe ihnen zumindest einen Hinweis darauf, auf was man achten sollte, wenn es einen äußeren Fall gibt.
Es scheint nicht so, als wäre dies eine destruktive Operation, da keine lokalen (nicht entfernten) Zweige gelöscht werden. Es scheint auch, dass dies eine gute Möglichkeit ist, nicht mehr verwendete Fernbedienungen aufzubauen, ohne regelmäßig git fetch --prune oder git remote prune zu spezifizieren.
Wenn das alles wahr ist, warum ist das nicht das Standardverhalten für Git?
Es ist nicht grundsätzlich gefährlich, und ich war versucht, es in meine eigenen --global Einstellungen zu setzen, aber ich habe es nie: hauptsächlich, weil es für mich auch relativ wenig Wert hat. 1
Wie Sie bemerken, besteht die Absicht im Wesentlichen darin, origin/zorg zu entfernen, sobald der Zweig zorg nicht mehr auf origin vorhanden ist. Da dies keine direkte Auswirkung auf Ihr eigenes zorg hat, ist es in der Regel harmlos und entschlüsselt Ihre Sicht auf Remote-Tracking-Zweige. Die einzigen zwei möglichen Nachteile sind:
Wenn jemand irrtümlich zorg im Upstream-Repository löscht und alle nachgeschalteten Kopien ihre origin/zorg beschneiden, verlieren Sie die ID des Commits (und möglicherweise viele Commits selbst) Das war die Spitze von zorg in diesem Upstream-Repository. So vergrößert es die Wirkung einiger Fehler. (Natürlich, wenn das Upstream-Repository so wichtig ist, sollten Sie wahrscheinlich trotzdem Backups erstellen. Wenn Sie jedoch die Klone als Backups verwenden, hat das automatische Bereinigen einen Nachteil. Natürlich können Sie das automatische Bereinigen immer speziell für diese deaktivieren Backups.)
Angenommen, Sie tun Ihre eigene zorg , die origin/zorg verfolgt, und die vorgelagerte zorg wird gelöscht (diesmal mit Absicht). Beachten Sie, dass es Ihre origin/zorg war, die Ihnen git status Informationen liefert, die Ihnen sagen, wie viele Commits Sie vor origin/zorg hatten. Angenommen, Sie möchten diese Commits nun verschieben , aber nicht "commits-this-used-to-be-upstream" in eine andere Ihrer eigenen Zweige. In diesem Fall macht die automatische Bereinigung Ihres eigenen origin/zorg es schwierig zu sagen, welche Commits Ihnen gehören und welche bereits im Upstream waren.
Beachten Sie, dass Sie in Fall 2 keine Commits verlieren . Was du verlierst, ist die Fähigkeit zu sagen, dass zB nur die letzten drei Commits, die momentan auf deinem zorg waren, deine eigenen waren, mit einigen davor (die jetzt in keinem anderen Zweig sind) war auf origin/zorg .
1 Im Laufe der Jahre wurde der Beschneidungscode manchmal etwas gebrochen, vor allem in Bezug auf das Nichtschneiden. Dies impliziert, dass die Git-Entwickler selbst wahrscheinlich nicht viel davon verwenden (aber die Dinge sollten jetzt besser sein, da es nun Tests in Gits interner Testsuite gibt, um sicherzustellen, dass das Beschneiden in neuen Releases korrekt funktioniert). Also zwischen "niedrigem Wert" und "ungenügendem Test in der Vergangenheit", das war zumindest zu der Zeit ein ausreichender Grund, es nicht zu setzen.
Tags und Links git git-remote git-fetch