Wann lösche ich Zweige in Git?

Angenommen, wir haben eine stabile Anwendung.

Morgen meldet jemand einen großen alten Fehler, den wir sofort beheben möchten. Also erstellen wir einen Zweig für diesen Hotfix aus "master", nennen ihn "2011_Hotfix" und drücken ihn nach oben, damit alle Entwickler bei der Behebung zusammenarbeiten können.

Wir beheben den Fehler und führen "2011_Hotfix" in "master" sowie in den aktuellen Entwicklungszweig ein. Und drücke "Meister".

Was machen wir jetzt mit "2011_Hotfix"? Sollte es bis zum Ende der Zeit für immer als Zweig da draußen bleiben oder sollten wir es jetzt löschen, da es seinen Zweck erfüllt hat? Es scheint unrein, nur überall Zweige herumliegen zu lassen, da die Liste der Zweige wahrscheinlich sehr lang wird, von denen die meisten nicht einmal mehr notwendig sind.

Was passiert mit der Historie, falls es gelöscht werden sollte? Wird das beibehalten, obwohl die eigentliche Filiale nicht mehr verfügbar ist? Wie würde ich einen Remote-Zweig entfernen?

Sie können einen Zweig mit sicher entfernen git branch -d yourbranch. Wenn es nicht zusammengeführte Änderungen enthält (dh Sie würden Commits verlieren, wenn Sie den Zweig löschen), wird git Sie darüber informieren und ihn nicht löschen.

Das Löschen eines zusammengeführten Zweigs ist also billig und lässt Sie keinen Verlauf verlieren.

Um einen Remote-Zweig zu löschen, verwenden Sie git push origin :mybranch, vorausgesetzt, Ihr Remote-Name ist Ursprung und der Remote-Zweig, den Sie löschen möchten, heißt mybranch.

Was Sie tun müssen, ist alles zu markieren, was Sie freigeben. Behalten Sie Zweige bei, wenn Sie sich aktiv entwickeln.

Löschen Sie alte Zweige mit

git branch -d branch_name

Löschen Sie sie vom Server mit

git push origin --delete branch_name

oder die alte Syntax

git push origin :branch_name

Dies lautet "Push nichts in branch_name am Ursprung".

Das heißt, solange die DAG (gerichteter azyklischer Graph) darauf hinweisen kann, werden die Commits in der Geschichte vorhanden sein.

Google "git-flow" und das kann mehr Einblick in Release-Management, Verzweigung und Tagging geben.

Da die Frage das "github" -Tag hat, möchte ich auch Folgendes hinzufügen: Insbesondere in Github wird dies nicht der Fall sein , wenn Sie einen Zweig per Pull-Request anfordern und dieser zusammengeführt wird (entweder über die Benutzeroberfläche oder durch Zusammenführen des Zweigs der Pull-Anfrage) Verlieren Sie die Pull-Anforderungsdaten (einschließlich Kommentare), auch wenn Sie den Zweig entfernen .

Eine Folge davon: Wenn Sie Pull-Anforderungen als Teil Ihres Workflows einbeziehen (der sich hervorragend in Codeüberprüfungen einfügt), können Sie Zweige sicher löschen, sobald sie zusammengeführt werden. Dies ist so alltäglich, dass Github kürzlich eine (süße) Funktion hinzugefügt hat, die direkt nach dem Zusammenführen einer Pull-Anforderung die Schaltfläche "Zweig löschen" öffnet.

Es ist jedoch zu beachten, dass jede Gruppe den Workflow übernehmen sollte, der am besten zu ihr passt (und dies kann dazu führen, dass solche Zweige gelöscht werden oder nicht). Mein aktuelles Arbeitsteam beschneidet beispielsweise alle Zweige, die nicht mit dem Master oder der Bereitstellung zusammenhängen (z. B. Produktion, Staging usw.), sobald ihre Pull-Anforderungen zusammengeführt werden, und wir haben immer noch die vollständige Verfolgung, wie sich die zugehörigen Commits gebildet haben jede schrittweise Verbesserung jedes Produkts.

Natürlich ersetzt keine Verlaufsverwaltung (Pull-Anforderungen oder auf andere Weise) das ordnungsgemäße Markieren von Versionen (die Sie vorzugsweise mit demselben Tool / Skript automatisieren, das eine Version bereitstellt / verpackt), sodass Sie jederzeit schnell zu den Benutzern wechseln können, auf denen sich Ihre Benutzer gerade befinden zu einem bestimmten Zeitpunkt. Das Taggen ist auch der Schlüssel zur Lösung Ihres ursprünglichen Problems: Wenn Sie feststellen, dass ein Zweig, der mit den "Arbeits" -Zweigen zusammengeführt wurde, gelöscht werden kann und sollte, und jeder Zweig, der mit einem Versions-Tag zusammengeführt wird, sollte "Produktion" usw. dies nicht tun Sie haben die Hotfixes immer aktiv, bis sie in eine zukünftige Version integriert sind.

Ich würde hinzufügen, dass der Nachteil des Löschens von Zweigen darin besteht, dass Sie alle Hyperlinks zu diesen Zweigen auf GitHub unterbrechen (diese Frage ist mit github gekennzeichnet). Sie erhalten eine 404 Not FoundFehlermeldung für diese Links. Aus diesem Grund ändere ich meine Links so, dass sie auf ein Commit oder Tag verweisen, nachdem ich einen Zweig auf GitHub gelöscht habe.

Da einige Links nicht geändert werden können, z. B. in E-Mails, vermeide ich jetzt, Hyperlinks zu GitHub-Zweigen vollständig zu erstellen und vom ersten Tag an auf ein Commit oder Tag zu verlinken.

Ich ziehe es vor, Zweige nach dem Zusammenführen zu löschen. Dies verhindert das visuelle Durcheinander einer langen Liste von Zweigen in Ihrem Repository. Diese Zweige werden auch an alle Gabeln des Repositorys weitergegeben.

Zuerst lösche ich meinen lokalen Zweig. Dies verhindert, dass es später versehentlich gedrückt wird.

git branch -d branchName

Dann lösche ich den Fernverfolgungszweig

git branch -dr remoteName\branchName

Dann lösche ich den Zweig auf GitHub. Ich benutze die Weboberfläche, aber der entsprechende Befehl ist unten.

git push remoteName :branchName

Selbst wenn der Zweig nie zusammengeführt wird, möchte ich die Commits normalerweise für die Nachwelt behalten. Ich möchte jedoch immer noch den Zweig löschen. Um die Commits zu verteilen und zu verhindern, dass sie vom Garbage Collector gefressen werden, erstelle ich ein mit Anmerkungen versehenes Tag, das auf dasselbe Commit wie der gelöschte Zweig verweist.

git tag -a tagName commitOrBranchName

Dann schiebe ich das Etikett auf Github

git push remoteName tagName

Es scheint, dass Sie den 2011_HotfixZweig löschen möchten, ohne seinen Verlauf zu verlieren. Ich werde zuerst die Löschung und dann die Geschichte besprechen.

Die üblichen gitMethoden zum Löschen von Zweigen wurden bereits oben beschrieben und funktionieren wie erwartet. githat keinen Befehl mit einem oder zwei Wörtern, der bedeutet: "Hey git, lösche sowohl den lokalen als auch den entfernten Zweig." Dieses Verhalten kann jedoch über ein Shell-Skript nachgeahmt werden. Nehmen Sie zum Beispiel Zach Holmans Shell-Skript 'git-nuke' . Es ist sehr einfach:

#!/bin/sh
git branch -D $1
git push origin :$1

Fügen Sie dies in eine ausführbare Datei (z. B. git-nuke) in einem Ihrer $PATHVerzeichnisse ein. Wenn Sie sich nicht in der 2011_HotfixVerzweigung befinden, werden durch einfaches Ausführen git-nuke 2011_Hotfixsowohl die lokalen als auch die Remote-Zweige gelöscht. Dies ist viel schneller und einfacher - wenn auch gefährlicher - als die Standardbefehle git.

Ihre Sorge um die Erhaltung der Geschichte ist gut. In diesem Fall brauchen Sie sich keine Sorgen zu machen. Sobald Sie verschmelzen 2011_Hotfixauf master, von allen Commits 2011_Hotfixhinzugefügt werden , um master‚Geschichte zu begehen. Kurz gesagt, Sie verlieren durch eine einfache Zusammenführung nicht den Verlauf.

Ich muss noch ein Wort hinzufügen, das vielleicht den Rahmen Ihrer Frage sprengt, aber dennoch relevant ist. Stellen wir uns vor, es gibt 20 winzige "Work-in-Progress" -Verpflichtungen 2011_Hotfix. Sie möchten jedoch, dass nur ein vollständiges Commit 2011_Hotfixzum Verlauf hinzugefügt wird master. Wie kombinieren Sie alle 20 kleinen Commits zu einem großen Commit? Glücklicherweise gitkönnen Sie mithilfe von mehrere Commits zu einem Commit zusammenfassen git-rebase. Ich werde hier nicht erklären, wie das funktioniert; Wenn Sie interessiert sind, ist die Dokumentation fürgit-rebase ausgezeichnet. Beachten Sie, dass der Verlauf neu geschrieben wird. git rebaseDaher sollte er mit Bedacht verwendet werden, insbesondere wenn Sie neu in diesem Bereich sind. Schließlich handelt Ihr 2011_HotfixSzenario von einem Entwicklerteam, nicht von einem Solo-Entwickler. Wenn Projektteammitglieder verwendengit rebaseEs ist ratsam, dass das Team explizite Richtlinien für die Verwendung von hat git rebase, damit ein Cowboy-Entwickler im Team die gitGeschichte eines Projekts nicht unabsichtlich beschädigt .

Wenn es erfolgreich wieder zusammengeführt und vielleicht sogar markiert wurde, würde ich sagen, dass es keine Verwendung mehr hat. So können Sie sicher tun git branch -d branchname.

Wenn Sie lokale Zweige beschneiden möchten, die vom Ursprung entfernt wurden, können Sie sie auch während der Verwendung beschneiden git fetch

git fetch --prune

Sie können Zweige in allen wichtigen Web-Benutzeroberflächen wie Github und BitBucket löschen. Nachdem Sie den Zweig online gelöscht haben, können Sie den lokalen Zweig mit löschen

git remote prune origin