Wie kann ich Git-Zweige archivieren?

Question

Ich habe einige alte Zweige in meinem Git-Repository, an denen nicht mehr aktiv gearbeitet wird. Ich möchte die Zweige archivieren, damit sie nicht standardmäßig angezeigt werden, wenn ich git branch -l -r . Ich möchte sie nicht löschen, weil ich den Verlauf beibehalten möchte. Wie kann ich das tun?

Ich weiß, dass es möglich ist, einen Schiedsrichter außerhalb von refs/heads zu erstellen. Zum Beispiel, refs/archive/old_branch . Gibt es irgendwelche Konsequenzen, wenn man das tut?

Answer 1

Hier ist ein Alias für das:

arc    = "! f() { git tag archive/$1 $1 && git branch -D $1;}; f"

Fügen Sie es so hinzu:

git config --global alias.arc '! f() { git tag archive/$1 $1 && git branch -D $1;}; f'

Denken Sie daran, dass es git archive Befehl bereits, so dass Sie nicht archive als Alias-Name.

Sie können auch einen Alias definieren, um die Liste der "archivierten" Zweige anzuzeigen:

arcl   = "! f() { git tag | grep '^archive/';}; f"

über das Hinzufügen von Aliasen

Answer 2

Ich verwende die folgenden Aliasnamen, um archivierte Zweige auszublenden:

[alias]
    br = branch --no-merge master # show only branches not merged into master
    bra = branch                  # show all branches

Also git br um aktiv entwickelte Zweige zu zeigen und git bra um alle Zweige anzuzeigen, einschließlich "archiviert" ein.

Answer 3

Ich würde keine Zweige archivieren. Mit anderen Worten: Zweige archivieren sich selbst. Sie wollen sicherstellen, dass die für Archäologen relevanten Informationen mit zuverlässigen Mitteln gefunden werden können. Zuverlässig insofern, als sie bei der täglichen Arbeit helfen und nicht einen zusätzlichen Schritt zur Erledigung der Arbeit hinzufügen. Das heißt, ich glaube nicht, dass die Leute daran denken werden, eine Markierung hinzuzufügen, wenn sie mit einem Zweig fertig sind.

Hier sind zwei einfache Schritte, die der Archäologie sehr helfen werden et Entwicklung.

1. Verknüpfen Sie jeden Aufgabenzweig mit einem zugehörigen Problem im Problemverfolgungssystem unter Verwendung einer einfachen Namenskonvention .
2. Verwenden Sie immer git merge --no-ff um Aufgabenzweige zusammenzuführen; Sie wollen die Zusammenführung von Commit und History Bubble, selbst für nur einen Commit.

Das war's. Warum? Weil ich als Code-Archäologe selten damit anfange, dass ich wissen will, welche Arbeiten an einem Zweig durchgeführt wurden. Sehr viel häufiger warum in aller Herrgottsfrühe ist der Code so geschrieben?! Ich muss den Code ändern, aber er hat einige merkwürdige Eigenschaften, und ich muss sie herausfinden, um nicht etwas Wichtiges zu zerstören.

Der nächste Schritt ist git blame um die zugehörigen Übertragungen zu finden, und hoffe dann, dass die Protokollmeldung aussagekräftig ist. Wenn ich tiefer graben muss, finde ich heraus, ob die Arbeit in einem Zweig gemacht wurde und lese den Zweig als Ganzes (zusammen mit dem Kommentar im Issue Tracker).

Sagen wir git blame zeigt auf die Verpflichtung XYZ. Ich öffne einen Git-Verlaufsbrowser (gitk, GitX, git log --decorate --graph , etc...), finden Sie Commit XYZ und sehen Sie...

AA - BB - CC - DD - EE - FF - GG - II ...
     \                       /
      QQ - UU - XYZ - JJ - MM

Da ist mein Zweig! Ich weiß, dass QQ, UU, XYZ, JJ und MM alle Teil desselben Zweigs sind und ich sollte mir ihre Logmeldungen für Details ansehen. Ich weiß, dass GG ein Merge-Commit sein wird und den Namen des Zweigs hat, der hoffentlich mit einem Problem im Tracker verbunden ist.

Wenn ich aus irgendeinem Grund einen alten Zweig finden möchte, kann ich Folgendes ausführen git log und suchen Sie nach dem Namen des Zweigs in der Zusammenführungsübergabe. Das ist selbst bei sehr großen Repositories schnell genug.

Das ist es, was ich meine, wenn ich sage, dass die Zweige sich selbst archivieren.

Die Kennzeichnung jedes Zweigs bedeutet unnötigen Mehraufwand bei der Erledigung von Aufgaben (ein kritischer Prozess, der rücksichtslos gestrafft werden sollte), überfrachtet die Tag-Liste (nicht im Hinblick auf die Leistung, sondern auf die Lesbarkeit) mit Hunderten von Tags, die nur gelegentlich nützlich sind, und ist nicht einmal für die Archäologie sehr nützlich.

Answer 4

Manchmal archiviere ich Zweige wie folgt:

1. Erzeugen von Patch-Dateien, z.B., format-patch <branchName> <firstHash>^..<lastHash> (erhalten Sie firstHash und lastHash mit git log <branchName> .
2. Verschieben Sie die generierten Patch-Dateien in ein Verzeichnis auf einem Dateiserver.
3. Löschen Sie den Zweig, z.B., git branch -D <branchName>

"Wenden Sie den Patch an, wenn Sie den Zweig wieder verwenden wollen; die Anwendung der Patch-Dateien (siehe git am ) kann je nach Zustand des Zielzweigs eine Herausforderung darstellen. Auf der positiven Seite hat dieser Ansatz den Vorteil, dass die Commits des Zweigs im Müll gesammelt werden können und Platz in Ihrem Repository sparen.

Answer 5

Schritt 0 . Vergewissern Sie sich, dass der Arbeitsbaum sauber ist, damit keine keine Arbeit zu verlieren:

git status

Schritt 1 . Checken Sie den Zweig im Stamm des lokalen Repositorys aus und markieren Sie ihn für die Archivierung:

git checkout <branch_name> && git tag archive/<branch_name>

Schritt 2 . Laden Sie die Tags in den Remote-Zweig hoch und stellen Sie sicher, dass Sie in einem anderen Zweig sind, bevor Sie fortfahren, zum Beispiel main :

git push origin --tags && git checkout main

Schritt 3 . Löschen Sie die Verzweigung aus den lokalen und entfernten Repositories:

git branch -D <branch_name> && git push origin -d <branch_name>

wo Sie ersetzen sollten <branch_name> mit dem Namen der Zweigstelle zu archivieren, und origin mit dem Namen des entfernten Repositorys falls anders als origin .

Kommentare:

• Vorher und nachher Stufe 1 können Sie Folgendes ausführen git tag zu bemerken, die Tag hinzugefügt.

• Vorher und nachher Stufe 3 möchten Sie vielleicht Folgendes sehen https://github.com/<github-username>/<github-repository-name>/branches und/oder laufen git branch -a um festzustellen, wie der Zweig gelöscht wurde.

• Um einen Zweig wiederherzustellen:

  git checkout -b <branch_name> archive/<branch_name>

gefolgt von

git push --set-upstream origin <branch_name>

Referenzen:
https://gist.github.com/zkiraly/c378a1a43d8be9c9a8f9
https://dev.to/clsource/archiving-git-branches-3k70