Skip to content

Instantly share code, notes, and snippets.

@rcanepa

rcanepa/Commit Formatting.md

Forked from clemtibs/Commit Formatting.md
Created May 18, 2017 16:31
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save rcanepa/d5ac22b6bd177c32193166251f84fd5f to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save rcanepa/d5ac22b6bd177c32193166251f84fd5f to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. @brianclements brianclements renamed this gist Dec 28, 2014. 1 changed file with 0 additions and 0 deletions.
    0 Commit Formatting → Commit Formatting.md
    View file
    File renamed without changes.
  2. @brianclements brianclements created this gist Dec 28, 2014.
    59 changes: 59 additions & 0 deletions Commit Formatting
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,59 @@
    ## Git Commit Guidelines

    We have very precise rules over how our git commit messages can be formatted. This leads to **more
    readable messages** that are easy to follow when looking through the **project history**. But also,
    we use the git commit messages to **generate the AngularJS change log**.

    ### Commit Message Format
    Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
    format that includes a **type**, a **scope** and a **subject**:

    ```
    <type>(<scope>): <subject>
    <BLANK LINE>
    <body>
    <BLANK LINE>
    <footer>
    ```

    Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
    to read on github as well as in various git tools.

    ### Type
    Must be one of the following:

    * **feat**: A new feature
    * **fix**: A bug fix
    * **docs**: Documentation only changes
    * **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
    semi-colons, etc)
    * **refactor**: A code change that neither fixes a bug or adds a feature
    * **perf**: A code change that improves performance
    * **test**: Adding missing tests
    * **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
    generation

    ### Scope
    The scope could be anything specifying place of the commit change. For example `$location`,
    `$browser`, `$compile`, `$rootScope`, `ngHref`, `ngClick`, `ngView`, etc...

    ### Subject
    The subject contains succinct description of the change:

    * use the imperative, present tense: "change" not "changed" nor "changes"
    * don't capitalize first letter
    * no dot (.) at the end

    ###Body
    Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes"
    The body should include the motivation for the change and contrast this with previous behavior.

    ###Footer
    The footer should contain any information about **Breaking Changes** and is also the place to
    reference GitHub issues that this commit **Closes**.


    A detailed explanation can be found in this [document][commit-message-format].

    [commit-message-format]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#