Was sind einige Beispiele für gängige Praktiken zur Benennung von Git-Zweigen?

Question

Ich verwende seit einigen Monaten ein lokales Git-Repository, das mit dem CVS-Repository meiner Gruppe zusammenarbeitet. Ich habe eine fast schon neurotische Anzahl von Zweigen erstellt, von denen die meisten glücklicherweise wieder in meinen Stamm eingeflossen sind. Aber die Namensgebung fängt an, ein Problem zu werden. Wenn ich eine Aufgabe habe, die sich leicht mit einem einfachen Label benennen lässt, aber ich erledige sie in drei Phasen, die jeweils ihre eigene Verzweigung und Zusammenführungssituation beinhalten, dann kann ich den Namen der Verzweigung jedes Mal wiederholen, aber das macht die Geschichte ein wenig verwirrend. Wenn ich in den Namen spezifischer werde, mit einer separaten Beschreibung für jede Stufe, dann werden die Zweignamen lang und unhandlich.

Ich habe beim Durchsehen alter Threads hier gelernt, dass ich anfangen könnte, Zweige mit einem / im Namen zu benennen, z. B. Thema/Aufgabe oder so ähnlich. Vielleicht fange ich damit an und schaue, ob es hilft, die Dinge besser zu organisieren.

Was sind die besten Praktiken für die Benennung von Git-Zweigen?

Bearbeiten: Niemand hat tatsächlich irgendwelche Namenskonventionen vorgeschlagen. Ich lösche Zweige, wenn ich mit ihnen fertig bin. Ich habe nur zufällig mehrere davon, weil das Management ständig meine Prioritäten ändert :) Ein Beispiel dafür, warum ich mehr als einen Zweig für eine Aufgabe brauche: Nehmen wir an, ich muss den ersten einzelnen Meilenstein der Aufgabe an das CVS-Repository der Gruppe übergeben. Zu diesem Zeitpunkt würde ich aufgrund meiner unvollkommenen Interaktion mit CVS diese Übergabe durchführen und dann den Zweig löschen. (Ich habe zu viele seltsame Interaktionen mit CVS erlebt, wenn ich versuche, denselben Zweig zu diesem Zeitpunkt weiter zu verwenden).

Answer 1

Hier sind einige der von mir verwendeten Konventionen zur Benennung von Zweigen und die Gründe dafür

Konventionen zur Benennung von Zweigen

1. Verwenden Sie Gruppierungszeichen (Wörter) am Anfang Ihrer Zweignamen.
2. Definieren und verwenden Sie kurze Lead-Token, um Zweige in einer Weise zu unterscheiden, die für Ihren Arbeitsablauf sinnvoll ist.
3. Verwenden Sie Schrägstriche, um Teile des Zweignamens zu trennen.
4. Verwenden Sie keine blanken Zahlen als führende Teile.
5. Vermeiden Sie lange beschreibende Namen für langlebige Zweige.

Gruppenmünzen

Verwenden Sie "Gruppierungs"-Zeichen vor den Namen Ihrer Zweige.

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

Die Gruppen können nach Belieben benannt werden, um sie an Ihren Arbeitsablauf anzupassen. Ich verwende gerne kurze Namen für meine Gruppen. Lesen Sie weiter, um mehr Klarheit zu erhalten.

Kurze wohldefinierte Token

Wählen Sie kurze Token, damit sie nicht zu viel Lärm zu jedem Ihrer Zweignamen hinzufügen. Ich verwende diese:

wip       Works in progress; stuff I know won't be finished soon
feat      Feature I'm adding or expanding
bug       Bug fix or experiment
junk      Throwaway branch created to experiment

Jedes dieser Token kann verwendet werden, um Ihnen mitzuteilen, zu welchem Teil Ihres Arbeitsablaufs jeder Zweig gehört.

Es klingt, als hätten Sie mehrere Zweige für verschiedene Änderungszyklen. Ich weiß nicht, welche Zyklen Sie haben, aber nehmen wir an, es sind "Neu", "Testen" und "Verifiziert". Sie können Ihre Zweige mit abgekürzten Versionen dieser Tags benennen, die immer gleich geschrieben werden, um sie zu gruppieren und um Sie daran zu erinnern, in welchem Stadium Sie sich befinden.

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

Sie können schnell erkennen, welche Zweige die verschiedenen Stadien erreicht haben, und Sie können sie mithilfe der Git-Optionen für den Musterabgleich leicht zusammenfassen.

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo

$ gitk --branches="*/foo"

Verwenden Sie Schrägstriche zur Trennung von Teilen

Sie können fast jedes beliebige Begrenzungszeichen in Zweignamen verwenden, aber ich finde, dass Schrägstriche am flexibelsten sind. Sie könnten Bindestriche oder Punkte bevorzugen. Aber mit Schrägstrichen können Sie einen Zweig umbenennen, wenn Sie ihn an einen entfernten Ort schieben oder von dort abrufen.

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

Für mich funktionieren Schrägstriche auch besser für die Tabulator-Erweiterung (Befehlsvervollständigung) in meiner Shell. So wie ich es konfiguriert habe, kann ich nach Zweigen mit verschiedenen Unterteilen suchen, indem ich die ersten Zeichen des Teils eingebe und die TAB-Taste drücke. Zsh liefert mir dann eine Liste von Verzweigungen, die mit dem Teil des Tokens übereinstimmen, das ich eingegeben habe. Dies funktioniert sowohl für vorangestellte als auch für eingebettete Token.

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar

$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

(Zshell ist in Bezug auf die Befehlsvervollständigung sehr konfigurierbar, und ich könnte es auch so konfigurieren, dass es Bindestriche, Unterstriche oder Punkte auf die gleiche Weise behandelt. Aber ich entscheide mich dagegen.)

Außerdem können Sie damit in vielen Git-Befehlen nach Zweigen suchen, z. B. so:

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*" 
gitk --branches="feature/*" 

Achtung: Wie Slipp in den Kommentaren anmerkt, können Schrägstriche Probleme verursachen. Da Verzweigungen als Pfade implementiert sind, kann man nicht eine Verzweigung mit dem Namen "foo" und eine andere Verzweigung mit dem Namen "foo/bar" haben. Dies kann für neue Benutzer verwirrend sein.

Keine bloßen Zahlen verwenden

Verwenden Sie keine bloßen Zahlen (oder Hexadezimalzahlen) als Teil des Namensschemas für die Verzweigung. Innerhalb der Tab-Erweiterung eines Referenznamens kann Git entscheiden, dass eine Zahl Teil eines sha-1 anstelle eines Zweignamens ist. Zum Beispiel benennt mein Fehlerverfolgungssystem Bugs mit Dezimalzahlen. Ich nenne meine zugehörigen Zweige CRnnnnn und nicht einfach nnnnn, um Verwechslungen zu vermeiden.

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

Wenn ich versuchen würde, nur 15032 zu erweitern, wäre Git unsicher, ob ich SHA-1s oder Zweignamen suchen wollte, und meine Auswahl wäre etwas eingeschränkt.

Vermeiden Sie lange, beschreibende Namen

Lange Zweignamen können sehr hilfreich sein, wenn Sie eine Liste von Zweigen betrachten. Bei einzeiligen Protokollen können sie jedoch hinderlich sein, da die Zweignamen den größten Teil der Zeile einnehmen und den sichtbaren Teil des Protokolls abkürzen können.

Andererseits können lange Zweignamen bei "Merge Commits" hilfreicher sein, wenn man sie nicht gewohnheitsmäßig von Hand umschreibt. Die Standardnachricht für das Zusammenführen von Übertragungen ist Merge branch 'branch-name' . Möglicherweise ist es hilfreicher, wenn Zusammenführungsnachrichten wie folgt angezeigt werden Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' statt nur Merge branch 'fix/CR15032' .

Answer 2

Ein erfolgreiches Git-Verzweigungsmodell von Vincent Driessen hat gute Vorschläge. Ein Bild ist unten zu sehen. Wenn Ihnen dieses Verzweigungsmodell zusagt, sollten Sie die Flow-Erweiterung zu Git . Andere haben kommentiert über Flow

Das Modell von Driessen umfasst

• Ein Master-Zweig, der nur für die Veröffentlichung verwendet wird. Typischer Name master .

• Ein "Entwicklungszweig", der von diesem Zweig abzweigt. Das ist der Zweig, der für die meisten Hauptarbeiten verwendet wird. Üblicherweise heißt er develop .

• Mehrere Funktionszweige aus dem Entwicklungszweig. Der Name basiert auf dem Namen des Features. Diese werden in den Entwicklungszweig zurückgeführt, nicht in den Master- oder Release-Zweig.

• Freigabezweig für Kandidatenversionen, die nur Fehlerkorrekturen und keine neuen Funktionen enthalten. Typischer Name rc1.1 .

Hotfixes sind kurzlebige Zweige für Änderungen, die vom Master stammen und in den Master gehen, ohne dass der Entwicklungszweig beteiligt ist.

Answer 3

Ich habe verschiedene Schemata, die ich gesehen habe, gemischt und an die von mir verwendeten Werkzeuge angepasst.
Mein kompletter Zweigniederlassungsname würde also lauten:

name/feature/issue-tracker-number/short-description

was sich wie folgt übersetzen lässt:

mike/blogs/RSSI-12/logo-fix

Die Teile sind durch Schrägstriche getrennt, da diese in SourceTree als Ordner interpretiert werden, um die Organisation zu erleichtern. Wir verwenden Jira für unsere Fehlerverfolgung, so dass die Angabe der Nummer das Nachschlagen im System erleichtert. Die Nummer macht es auch durchsuchbar, wenn man versucht, das Problem in Github zu finden, wenn man versucht, einen Pull Request einzureichen.

Answer 4

Ich persönlich bevorzuge es, den Zweignamen zu löschen, wenn ich mit einem Themenzweig fertig bin.

Anstatt den Namen der Verzweigung zu verwenden, um die Bedeutung der Verzweigung zu erklären, beginne ich die Betreffzeile der Commit-Nachricht bei der ersten Commit-Übertragung auf dieser Verzweigung mit "Verzweigung:" und füge weitere Erklärungen in den Text der Nachricht ein, wenn der Betreff nicht genug Platz bietet.

Der Zweigname ist bei mir nur ein Handle, um auf einen Themenzweig zu verweisen, während ich an ihm arbeite. Sobald die Arbeit am Themenzweig abgeschlossen ist, entferne ich den Zweignamen, manchmal markiere ich den Commit für eine spätere Referenz.

Das macht die Ausgabe von git branch auch nützlicher: Es werden nur langlebige Zweige und aktive Themenzweige aufgelistet, nicht alle Zweige überhaupt.

Answer 5

Warum braucht es für jede Aufgabe drei Verzweigungen/Merges? Können Sie das näher erläutern?

Wenn Sie ein Fehlerverfolgungssystem verwenden, können Sie die Fehlernummer als Teil des Zweignamens verwenden. Dadurch bleiben die Zweignamen eindeutig, und Sie können ihnen ein oder zwei kurze und beschreibende Wörter voranstellen, um sie für Menschen lesbar zu halten, wie "ResizeWindow-43523" . Das macht es auch einfacher, wenn man Zweige aufräumen will, da man den zugehörigen Fehler nachschlagen kann. So benenne ich normalerweise meine Zweige.

Da diese Zweige schließlich wieder in Master zusammengeführt werden, sollten Sie sie nach dem Zusammenführen sicher löschen können. Es sei denn, Sie fusionieren mit --squash Die gesamte Historie der Filiale ist noch vorhanden, falls Sie sie einmal brauchen sollten.