Antworten:
ich benutze
[Abc]: Message.
Mit Add, Mod (ify), Ref (actoring), Fix, Rem (ove) und Rea (dability) ist es einfach, Logfiles zu extrahieren.
Beispiel
Add: New function to rule the world.
Mod: Add women factor in Domination.ruleTheWorld().
Ref: Extract empathy stuff to an abstract class.
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.
Rem: freeSpeech is not used anymore.
Rea: Removed old TODO and extra space in header.
Wenn ich mehr als eine Zeile habe, sortiere ich sie mit dem Wichtigsten zuerst.
Modund erklären Ref? Manchmal mache ich nur kleine Korrekturen, was eine Art Refactoring ist.
Modgeht es darum, etwas hinzuzufügen oder ein Verhalten Refzu ändern, interne Dinge zu ändern , die keine Funktionalität, API usw. hinzufügen. Beispiel: Wenn ich eine add(Object)Funktion habe und eine add(List<Object>)Funktion implementiere , kommentiere ich mit Mod. Später entferne ich die Vervielfältigung und verwende sie direkt add(Object)in der von add(List<Object>)mir verwendeten Form Ref.
Wir verwenden folgendes:
[Ticket-ID in JIRA]: [Meldung: Was wurde getan?] Zum Beispiel - ABC-123: Möglichkeit hinzugefügt, die Präsentation pro Region zu konfigurieren.
In diesem Fall können Sie bei ordnungsgemäßer Integration geänderte / gelöschte / hinzugefügte Dateien in Ihren Issue-Tracker übernehmen. Beachten Sie jedoch, dass Sie so etwas wie ABC-123: Done oder ABC-123: Fixed mit Filtern nach Möglichkeit verhindern sollten.
Es gibt eine einfache Regel, die eine Konvention ist, die von vielen (wenn nicht allen) SCMs und von den meisten Tools befolgt wird, die mit SCMs arbeiten:
Die erste Zeile einer Festschreibungsnachricht ist eine kurze Zusammenfassung, während der Rest der Nachricht die Details enthält.
Daher zeigen die meisten Tools nur die erste Zeile und die gesamte Nachricht bei Bedarf an.
Ein typischer Missbrauch einer Festschreibungsmeldung ist eine Aufzählung der Änderungen (nur der erste Aufzählungspunkt wird angezeigt). Ein weiterer Missbrauch besteht darin, eine zu lange detaillierte Nachricht in eine einzige Zeile zu schreiben.
Wenn es also eine Sache gibt, die erzwungen werden muss, würde ich sagen, dass es die maximale Länge der ersten Zeile ist.
Persönlich habe ich noch nie eine allgemeine Commit-Vorlage gesehen, die es wert ist, verwendet zu werden. In dem Kommentar sollte genau angegeben werden, mit welchen Commits es zu tun hat, z. B. welche Funktion / Fehlerbehebung oder eine kurze Erklärung, warum Änderungen vorgenommen wurden.
Informationen darüber, was zugesagt wurde, sollten nicht enthalten sein, dies kann vom scm-System bestimmt werden. Weitere Informationen zu Fehlern und Funktionen finden Sie dort, wo Fehler und Funktionen nachverfolgt werden.
Wenn ich einen Fehlerbericht nach einem Commit aktualisiere, finde ich es gut, die Commit-Revision zusammen mit den Kommentaren im Fehlerbericht anzugeben. Auf diese Weise finden Sie den Weg vom Festschreibungskommentar zum Fehlerbericht, und für jeden Kommentar im Fehlerbericht können Sie feststellen, was festgeschrieben wurde. Sie duplizieren jedoch keine Informationen, indem Sie diese sowohl im Fehlerbericht als auch in der Festschreibungsmeldung angeben.
Wenn Sie dann den Verlauf von Revisionen für eine Datei anzeigen, erhalten Sie eine kurze Beschreibung des Verlaufs. Sie wissen jedoch auch, wo Sie nach weiteren Details suchen müssen, um Fehlerberichte oder Aufgabenbeschreibungen zu erhalten.
In Git ist es möglich, fast alles mit Git-Hooks zu erzwingen . Überprüfen Sie die Beispiele in .git / hooks auf Ideen.
In Bezug auf die Nachricht möchten Sie in einem sehr allgemeinen Fall genügend Informationen über das von Ihnen gelöste Problem UND die Lösung selbst einfügen, um dieses Commit später finden und identifizieren zu können. In den meisten Fällen wird dem Problem eine Fehlernummer zugeordnet (bei ordnungsgemäßer Integration in Ihr Fehlerverfolgungssystem). Wenn Sie über andere Systeme verfügen, in die Ihr Prozess integriert ist (z. B. das Code Review Tracking-System), geben Sie auch die entsprechenden Bits an:
Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.
BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none
ABER du willst es einfach halten. Andernfalls finden die Benutzer eine Möglichkeit, das System zu betrügen und unbrauchbare Commit-Nachrichten zu erstellen.
Wir verwenden eine Vorlage mit
Die ersten beiden werden jedoch die meiste Zeit weggelassen (gelegentlich alle drei), so dass es nicht wirklich eine große Sache ist.
Ich habe in der Regel die Kennung, die sich in dem von mir verwendeten Ticket-Tracking-System befindet, oder eine übergeordnete Übersicht als erste Zeile. Dann habe ich Punkt "Aufzählungszeichen" der spezifischen Änderung im Festschreiben. So könnte ich von etwas wie:
MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity
Dies ist das sauberste Commit-Format, das ich mag. Es ist direkt und auf den Punkt. Ein weiterer Grund, warum ich das so mache, ist, dass ich, wenn ich ein Änderungsprotokoll erstellen möchte, einfach alle Commit-Meldungen in ein Änderungsprotokoll schreiben kann.
[ticketId] [ABC] [topicId] [WIP] Nachricht, wobei:
Beispiele:
[# 452567] [hinzufügen] [menu_item] neues Element - Gästebuch
[# 452363] [fix] [banner_top] [WIP] 1024x300 kann jetzt verwendet werden
[# 452363] [fix] [banner_top] 500x200 kann jetzt verwendet werden
[ # 452713] [rem] [Seite] linke mittlere Anzeige