Changes between Version 16 and Version 17 of TracDev/DevelopmentWorkflow

Timestamp:

Aug 29, 2017, 9:07:03 PM (7 years ago)

Author:

Ryan J Ollos

Comment:

Add commit message guidelines, modified from ​jQuery guidelines.

TracDev/DevelopmentWorkflow

@@ -10 +10 @@
 
 When there are many iterations or spin-off changes needed, it's a good idea to start a branch, either in the svn [source:sandbox] for those who have the commit permission or inside an external DVCS repository, by forking our Mercurial or Git mirrors (see TracRepositories).
+
+== Writing Commit Messages
+
+What follows is a brief outline of what constitutes a good commit message. More extensive guidelines can be found [https://chris.beams.io/posts/git-commit/ here] and [https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project here].
+
+Commits should be atomic. If three separate issues are being fixed (unless they are all fixed by one change), they need to be done as three separate commits. This also applies to whitespace and style changes, which should be done in their own commit. Whitespace commits should not include code or content changes. Accordingly, code change commits should not include whitespace changes (unless the whitespace changes are on the same lines as the code being changed).
+
+Commit messages should describe what changed, and reference the issue number if the commit closes or is associated with a particular issue. Example:
+
+{{{
+Version: Short Description
+ 
+Optional Long Description
+ 
+Refs #zzz
+}}}
+
+=== Subject
+
+This is the first line. It consists of the development version, like `1.2.2dev`. This line must be 72 characters or less. There should be no full stop (period) at the end and the imperative form should be used (example: //Add a command for setting wiki attributes//).
+
+=== Long description
+
+There are two line breaks between the subject and the long description. The description can have any length and formatting, like lists, but it must be hard-wrapped at 80 characters.
+
+=== References
+
+List the issues being addressed, using either `Refs` or `Fixes`. A comma-separated list of issues can be used: `Refs #12, #34`.
 
 == Integration in release branches