Skip to content

Instantly share code, notes, and snippets.

Revisions

  1. @robertpainsi robertpainsi revised this gist Feb 18, 2018. 1 changed file with 19 additions and 3 deletions.
    22 changes: 19 additions & 3 deletions commit-message-guidelines.md
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,6 @@
    ## Commit Message Guidelines
    ```
    #<IssueId> Short (72 chars or less) summary
    Short (72 chars or less) summary
    More detailed explanatory text. Wrap it to 72 characters. The blank
    line separating the summary from the body is critical (unless you omit
    @@ -19,7 +19,7 @@ Further paragraphs come after blank lines.

    ### Example for a commit message
    ```
    #1234 Add CPU arch filter scheduler support
    Add CPU arch filter scheduler support
    In a mixed environment of…
    ```
    @@ -32,7 +32,7 @@ If applied, this commit will *\<your subject line here\>*
    * Do not end the subject line with a period
    * Capitalize the subject line and each paragraph
    * Use the imperative mood in the subject line
    * Wrap the body at 72 characters
    * Wrap lines at 72 characters
    * Use the body to explain what and why you have done something. In most cases, you can leave out details about how a change has been made.

    ### Information in commit messages
    @@ -48,6 +48,22 @@ If applied, this commit will *\<your subject line here\>*

    Details for each point and good commit message examples can be found on https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages

    ### References in commit messages
    If the commit refers to an issue, add this information to the commit message header or body. e.g. the GitHub web platform automatically converts issue ids (e.g. #123) to links referring to the related issue. For issues tracker like Jira there are plugins which also converts Jira tickets, e.g. [Jirafy](https://chrome.google.com/webstore/detail/jirafy/npldkpkhkmpnfhpmeoahhakbgcldplbj).

    In header:
    ```
    [#123] Refer to GitHub issue…
    ```
    ```
    CAT-123 Refer to Jira ticket with project identifier CAT…
    ```
    In body:
    ```
    Fixes #123, #124
    ```

    ### Sources
    * http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
    * https://wiki.openstack.org/wiki/GitCommitMessages
  2. @robertpainsi robertpainsi revised this gist May 2, 2017. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions commit-message-guidelines.md
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,6 @@
    ## Commit Message Guidelines
    ```
    Issue #<IssueId>: Short (72 chars or less) summary
    #<IssueId> Short (72 chars or less) summary
    More detailed explanatory text. Wrap it to 72 characters. The blank
    line separating the summary from the body is critical (unless you omit
    @@ -19,7 +19,7 @@ Further paragraphs come after blank lines.

    ### Example for a commit message
    ```
    Issue #1234: Add CPU arch filter scheduler support
    #1234 Add CPU arch filter scheduler support
    In a mixed environment of…
    ```
  3. @robertpainsi robertpainsi created this gist May 2, 2017.
    54 changes: 54 additions & 0 deletions commit-message-guidelines.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,54 @@
    ## Commit Message Guidelines
    ```
    Issue #<IssueId>: Short (72 chars or less) summary
    More detailed explanatory text. Wrap it to 72 characters. The blank
    line separating the summary from the body is critical (unless you omit
    the body entirely).
    Write your commit message in the imperative: "Fix bug" and not "Fixed
    bug" or "Fixes bug." This convention matches up with commit messages
    generated by commands like git merge and git revert.
    Further paragraphs come after blank lines.
    - Bullet points are okay, too.
    - Typically a hyphen or asterisk is used for the bullet, followed by a
    single space. Use a hanging indent.
    ```

    ### Example for a commit message
    ```
    Issue #1234: Add CPU arch filter scheduler support
    In a mixed environment of…
    ```

    ### A properly formed git commit subject line should always be able to complete the following sentence
    If applied, this commit will *\<your subject line here\>*

    ### Rules for a great git commit message style
    * Separate subject from body with a blank line
    * Do not end the subject line with a period
    * Capitalize the subject line and each paragraph
    * Use the imperative mood in the subject line
    * Wrap the body at 72 characters
    * Use the body to explain what and why you have done something. In most cases, you can leave out details about how a change has been made.

    ### Information in commit messages
    * Describe why a change is being made.
    * How does it address the issue?
    * What effects does the patch have?
    * Do not assume the reviewer understands what the original problem was.
    * Do not assume the code is self-evident/self-documenting.
    * Read the commit message to see if it hints at improved code structure.
    * The first commit line is the most important.
    * Describe any limitations of the current code.
    * Do not include patch set-specific comments.

    Details for each point and good commit message examples can be found on https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages

    ### Sources
    * http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
    * https://wiki.openstack.org/wiki/GitCommitMessages
    * http://chris.beams.io/posts/git-commit/