Search code examples
gitgit-commit

Format of Git commit messages

What is the name of the format of these Git commit messages?

fix(short message): expanded message
docs(short message): expanded message
feat(short message): expanded message
refactor(short message): expanded message
Solution

  • You find that convention in Karma

    <type>(<scope>): <subject>

<body>

<footer>

    It can help for:

    • automatic generation of the changelog
    • simple navigation through git history (eg. ignoring style changes)

    Karma's convention include:

    Allowed <type> values:

    • feat (new feature for the user, not a new feature for build script)
    • fix (bug fix for the user, not a fix to a build script)
    • docs (changes to the documentation)
    • style (formatting, missing semi colons, etc; no production code change)
    • refactor (refactoring production code, eg. renaming a variable)
    • test (adding missing tests, refactoring tests; no production code change)
    • chore (updating grunt tasks etc; no production code change)

    Example <scope> values:

    • init
    • runner
    • watcher
    • config
    • web-server
    • proxy
    • etc.

    Note: a git commit message should not start with blank lines or empty lines.
    It is not illegal, but with git 2.10 (Q3 2016), such lines will be trimmed by default for certain operations.

    See commit 054a5ae, commit 88ef402, commit 84e213a, commit 84e213a (29 Jun 2016), commit 88ef402, commit 84e213a (29 Jun 2016), commit 84e213a (29 Jun 2016), and commit 4e1b06d, commit 7735612 (22 Jun 2016) by Johannes Schindelin (dscho).
    (Merged by Junio C Hamano -- gitster -- in commit 62e5e83, 11 Jul 2016)

    reset --hard: skip blank lines when reporting the commit subject

    When there are blank lines at the beginning of a commit message, the pretty printing machinery already skips them when showing a commit subject (or the complete commit message).
    We shall henceforth do the same when reporting the commit subject after the user called

    git reset --hard <commit>

    commit -C: skip blank lines at the beginning of the message

    (that is when you take an existing commit object, and reuse the log message and the authorship information (including the timestamp) when creating the commit)

    Consistent with the pretty-printing machinery, we skip leading blank lines (if any) of existing commit messages.

    While Git itself only produces commit objects with a single empty line between commit header and commit message, it is legal to have more than one blank line (i.e. lines containing only white space, or no characters) at the beginning of the commit message, and the pretty-printing code already handles that.

    commit.c: make find_commit_subject() more robust

    Just like the pretty printing machinery, we should simply ignore blank lines at the beginning of the commit messages.

    This discrepancy was noticed when an early version of the rebase--helper produced commit objects with more than one empty line between the header and the commit message.