Frage git branch naming best practices [geschlossen]


Ich benutze seit einigen Monaten ein lokales Git-Repository, das mit dem CVS-Repository meiner Gruppe interagiert. Ich habe eine fast neurotische Anzahl von Ästen gemacht, von denen die meisten glücklicherweise in meinen Stamm zurückgewachsen sind. Aber die Namensgebung wird langsam zum Problem. Wenn ich eine Aufgabe einfach mit einem einfachen Label benennen kann, aber ich beende sie in drei Stufen, die jeweils ihre eigene Verzweigungs- und Zusammenführungssituation beinhalten, dann kann ich den Verzweigungsnamen jedes Mal wiederholen, aber das macht die Geschichte etwas verwirrend. Wenn ich genauer in den Namen mit einer separaten Beschreibung für jede Stufe komme, dann beginnen die Verzweigungsnamen, lang und unhandlich zu werden.

Ich habe gelernt, alte Threads hier zu durchsuchen, die ich anfangen könnte, Zweige mit einem / in dem Namen zu benennen, d. H. Thema / Aufgabe oder etwas ähnliches. Ich kann damit anfangen und schauen, ob es hilft, die Dinge besser organisiert zu halten.

Was sind Best Practices für die Benennung von Git-Zweigen?

Bearbeiten: Niemand hat tatsächlich Namenskonventionen vorgeschlagen. Ich lösche Zweige, wenn ich mit ihnen fertig bin. Ich habe zufällig mehrere rum, weil das Management ständig meine Prioritäten ändert. :) Als ein Beispiel, warum ich mehr als einen Zweig für eine Aufgabe brauche, nehme ich an, dass ich den ersten diskreten Meilenstein in der Aufgabe dem CVS-Repository der Gruppe übergeben muss. Zu diesem Zeitpunkt würde ich aufgrund meiner unvollkommenen Interaktion mit CVS diesen Commit durchführen und dann diesen Zweig töten. (Ich habe zu viel Seltsamkeit bei der Interaktion mit CVS gesehen, wenn ich versuche, zu diesem Zeitpunkt den gleichen Zweig weiter zu verwenden.)


787
2017-11-07 21:29


Ursprung


Antworten:


Hier sind einige Branchennamenskonventionen, die ich verwende, und die Gründe dafür

Branchennamenskonventionen

  1. Verwenden Sie Gruppierungstokens (Wörter) am Anfang Ihrer Zweigstellennamen.
  2. Definieren und verwenden Sie kurze Lead-Tokens, um Zweige auf eine für Ihren Workflow sinnvolle Weise zu unterscheiden.
  3. Verwenden Sie Schrägstriche, um Teile Ihrer Zweigstellennamen zu trennen.
  4. Verwenden Sie keine nackten Zahlen als führende Teile.
  5. Vermeiden Sie lange beschreibende Namen für langlebige Zweige.

Gruppentoken

Verwenden Sie "Gruppierungs" Token vor Ihren Zweignamen.

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

Die Gruppen können beliebig benannt werden, damit sie zu Ihrem Workflow passen. Ich verwende gerne kurze Substantive für meine. Lesen Sie weiter für mehr Klarheit.

Kurze gut definierte Token

Wählen Sie kurze Tokens, damit sie nicht zu viel Rauschen zu jedem Ihrer Zweignamen hinzufügen. Ich benutze 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 Workflows jeder Zweig gehört.

Es klingt, als ob Sie mehrere Zweige für verschiedene Zyklen einer Änderung haben. Ich weiß nicht, was Ihre Zyklen sind, aber nehmen wir an, sie sind "neu", "testen" und "verifiziert". Du kannst deine Zweige mit abgekürzten Versionen dieser Tags benennen, die immer auf die gleiche Weise geschrieben werden, um sie zu gruppieren und dich daran zu erinnern, in welcher Phase du dich befindest.

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

Sie können schnell feststellen, welche Zweige die einzelnen Phasen erreicht haben, und Sie können sie einfach mit den Pattern-Optionen von Git gruppieren.

$ 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, um Teile zu trennen

Sie können die meisten beliebigen Trennzeichen in den Zweignamen verwenden, aber ich finde Schrägstriche als die flexibelsten. Vielleicht bevorzugen Sie Bindestriche oder Punkte. Durch Schrägstriche können Sie beim Umleiten oder Abrufen von einer Remote-Station Branch-Umbenennungen vornehmen.

$ 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 Tab-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 eintippe und die TAB-Taste drücke. Zsh gibt mir dann eine Liste von Zweigen, die dem Teil des Tokens entsprechen, den ich eingegeben habe. Dies funktioniert sowohl für vorangehende als auch für eingebettete Tokens.

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


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

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

Außerdem können Sie in vielen Git-Befehlen nach Zweigen suchen:

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

Vorbehalt: Wie Slipp in den Kommentaren hervorhebt, können Schrägstriche Probleme verursachen. Da Verzweigungen als Pfade implementiert sind, können Sie keine Verzweigung namens "foo" und eine andere Verzweigung namens "foo / bar" verwenden. Dies kann für neue Benutzer verwirrend sein.

Verwenden Sie keine nackten Zahlen

Verwenden Sie keine nackten Zahlen (oder Hex-Zahlen) als Teil Ihres Verzweigungsbenennungsschemas. Innerhalb der Tab-Erweiterung eines Referenznamens kann git entscheiden, dass eine Nummer Teil eines sha-1 statt eines Zweignamens ist. Zum Beispiel benennt mein Issue Tracker Fehler mit Dezimalzahlen. Ich benenne meine verwandten Zweige CRnnnnn anstatt nur nnnnn, um Verwirrung zu vermeiden.

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

Wenn ich versuchen würde, nur 15032 zu erweitern, wäre Git nicht sicher, ob ich nach SHA-1-Namen oder Filialnamen suchen möchte, und meine Auswahl wäre etwas eingeschränkt.

Vermeiden Sie lange beschreibende Namen

Lange Verzweigungsnamen können sehr hilfreich sein, wenn Sie sich eine Liste von Zweigen ansehen. Aber es kann bei der Betrachtung von verzierten Einstrichprotokollen im Weg stehen, da die Zweignamen den größten Teil der einzelnen Zeile auffressen und den sichtbaren Teil des Protokolls abkürzen können.

Auf der anderen Seite können lange Branch-Namen hilfreicher sein bei "Merge-Commits", wenn sie nicht von Hand neu geschrieben werden. Die Standardnachricht zum Zusammenführen von Commit ist Merge branch 'branch-name'. Es kann hilfreicher sein, wenn Merge-Nachrichten als angezeigt werden Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' statt nur Merge branch 'fix/CR15032'.


714
2018-05-19 23:25



Ein erfolgreiches Git-Verzweigungsmodell von Vincent Driessen hat gute Vorschläge. Ein Bild ist unten. Wenn dieses Verzweigungsmodell Sie anspricht, ziehen Sie die Flow-Erweiterung zu Git. Andere haben über den Fluss kommentiert

Driessens Modell beinhaltet

  • Ein Masterzweig, der nur für die Freigabe verwendet wird. Typischer Name master.

  • Ein "entwickeln" Zweig von diesem Zweig. Das ist derjenige, der für die meisten Hauptarbeit verwendet wird. Häufig benannt develop.

  • Mehrere Funktionen verzweigen vom Entwicklungszweig. Name basierend auf dem Namen des Features. Diese werden wieder in Entwicklung, nicht in die Master- oder Release-Zweige zusammengeführt.

  • Release Branch, um Kandidaten-Releases zu halten, mit nur Bugfixes und keine neuen Features. Typischer Name rc1.1.

Hotfixes sind kurzlebige Verzweigungen für Änderungen, die vom Master kommen und in Master übernommen werden, ohne dass der Entwicklungszweig involviert ist.

enter image description here


227
2017-11-23 16:58



Meine persönliche Vorliebe ist, den Zweignamen zu löschen, nachdem ich mit einer Zweigstelle fertig bin.

Anstatt zu versuchen, den Verzweigungsnamen zu verwenden, um die Bedeutung der Verzweigung zu erklären, starte ich die Betreffzeile der Übergabenachricht im ersten Commit für diesen Zweig mit "Branch:" und füge weitere Erläuterungen in den Nachrichtentext des Betreffs ein gibt mir nicht genug Platz.

Der Zweigname, den ich verwende, ist nur ein Handle, um auf einen Zweig des Themas zu verweisen, während ich daran arbeite. Sobald die Arbeit an der Zweigstelle abgeschlossen ist, werde ich den Zweignamen los und markiere das Commit manchmal für eine spätere Referenz.

Das macht die Ausgabe von git branch nützlicher auch: es listet nur langlebige Zweige und aktive Zweige auf, nicht alle Zweige jemals.


42
2017-11-07 21:51



Ich habe verschiedene Schemata, die ich gesehen habe und basierend auf den Werkzeugen, die ich benutze, gemischt. Also mein abgeschlossener Zweigname wäre:

Name / Merkmal / Issue-Tracker-Nummer / Kurzbeschreibung

was würde bedeuten:

Mike / Blogs / RSSI-12 / Logo-Fix

Die Teile sind durch Schrägstriche getrennt, da diese zur einfachen Organisation als Ordner in SourceTree interpretiert werden. Wir verwenden Jira für unsere Problemverfolgung, so dass die Angabe der Nummer es erleichtert, im System nachzuschlagen. Wenn Sie diese Zahl eingeben, wird sie auch durchsuchbar, wenn Sie versuchen, dieses Problem in Github zu finden, wenn Sie versuchen, eine Pull-Anforderung zu senden.


25
2017-10-10 15:58



Warum braucht es für jede Aufgabe drei Verzweigungen / Zusammenführungen? Kannst du mehr darüber erklären?

Wenn Sie ein Fehlerverfolgungssystem verwenden, können Sie die Fehlernummer als Teil des Verzweigungsnamens verwenden. Dadurch bleiben die Zweignamen eindeutig, und Sie können ihnen ein kurzes und beschreibendes Wort voranstellen, damit sie lesbar bleiben "ResizeWindow-43523". Es hilft auch, Dinge zu erleichtern, wenn Sie Zweige aufräumen, da Sie den zugehörigen Fehler nachschlagen können. So nenne ich normalerweise meine Zweige.

Da diese Zweige schließlich wieder in den Master zusammengeführt werden, sollten Sie sie nach dem Zusammenführen sicher löschen. Es sei denn, Sie verschmelzen mit --squash, die gesamte Geschichte der Branche wird immer noch existieren, sollten Sie es jemals brauchen.


19
2017-11-11 06:24



Beachten Sie, wie in der committe e703d7 oder commit b6c2a0d  (März 2014), jetzt Teil von Git 2.0, finden Sie eine weitere Namenskonvention (die Sie auf Zweigstellen anwenden können).

"Wenn Sie Leerzeichen verwenden müssen, verwenden Sie den Gedankenstrich" ist eine seltsame Art zu sagen, dass Sie kein Leerzeichen verwenden dürfen.
  Da es in der Befehlszeilenbeschreibung häufiger üblich ist, mehrere Wörter zu verwenden, möchten Sie an diesen Stellen nicht einmal Leerzeichen verwenden.

Ein Zweigname darf keinen Platz haben (siehe "Welche Zeichen sind innerhalb eines Filialnamens illegal?" und git check-ref-format Man Seite).

Also für jeden Zweignamen, der durch einen Mehrwortausdruck repräsentiert wäre, unter Verwendung eines '-'(Strich) als Trennzeichen ist eine gute Idee.


7
2018-06-14 19:41



In Anlehnung an den Vorschlag von farktronix haben wir Jira-Ticketnummern für ähnliche in mercurial verwendet, und ich plane, sie weiterhin für Git-Filialen zu verwenden. Aber ich denke, die Ticketnummer selbst ist wahrscheinlich einzigartig genug. Während es hilfreich sein kann, ein beschreibendes Wort im Zweignamen zu haben, wie farktronix feststellt, möchten Sie wahrscheinlich weniger tippen, wenn Sie häufig zwischen Zweigen wechseln. Wenn Sie den Namen des Zweiges wissen müssen, suchen Sie in Jira nach den zugehörigen Stichwörtern im Ticket, wenn Sie es nicht wissen. Außerdem sollten Sie die Ticketnummer in jeden Kommentar einfügen.

Wenn Ihr Zweig eine Version darstellt, scheint es, dass die allgemeine Konvention darin besteht, das xxx-Format (Beispiel: "1.0.0") für Zweignamen und vx.xx (Beispiel "v1.0.0") für Tag-Namen zu verwenden (um Konflikte zu vermeiden). . Siehe auch: is-there-ein-Standard-Namenskonvention-für-Git-Tags


4
2018-01-27 21:31