Edgewall Software

Changes between Version 16 and Version 17 of TracDev/DevelopmentWorkflow

Aug 29, 2017, 9:07:03 PM (2 years ago)
Ryan J Ollos

Add commit message guidelines, modified from jQuery guidelines.


  • TracDev/DevelopmentWorkflow

    v16 v17  
    1111When 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).
     13== Writing Commit Messages
     15What 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].
     17Commits 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).
     19Commit messages should describe what changed, and reference the issue number if the commit closes or is associated with a particular issue. Example:
     22Version: Short Description
     24Optional Long Description
     26Refs #zzz
     29=== Subject
     31This 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//).
     33=== Long description
     35There 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.
     37=== References
     39List the issues being addressed, using either `Refs` or `Fixes`. A comma-separated list of issues can be used: `Refs #12, #34`.
    1341== Integration in release branches