Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
# Type(<scope>): <subject>
# <body>
# <footer>
# Type should be one of the following:
# * feat (new feature)
# * fix (bug fix)
# * docs (changes to documentation)
# * style (formatting, missing semi colons, etc; no code change)
# * refactor (refactoring production code)
# * test (adding missing tests, refactoring tests; no production code change)
# * chore (updating grunt tasks etc; no production code change)
# Scope is just the scope of the change. Something like (admin) or (teacher).
# Subject should use impertivite tone and say what you did.
# The body should go into detail about changes made.
# The footer should contain any JIRA (or other tool) issue references or actions.
# For a full example of how to write a good commit message, check out
# ---------------------------------------------------------------------------------
# Jira Issue Processing
# ISSUE_KEY #comment This is a comment
# ISSUE_KEY #done
# ---------------------------------------------------------------------------------

This comment has been minimized.

Copy link
Owner Author

@Linell Linell commented Feb 12, 2015

curl >> ~/.git-commit-template.txt

git config --global commit.template ~/.git-commit-template.txt

This comment has been minimized.

Copy link

@somazx somazx commented Mar 1, 2015

Can you explain or give more examples of "body should be imperative tone".

[Edit: googled around and found this:]


This comment has been minimized.

Copy link
Owner Author

@Linell Linell commented Jun 18, 2015

@somazx I'm sorry, I just saw your comment.

But yeah, I think this answer on that question sums it up very well:

The use of the imperative, present tense is one that takes a little getting used to. When I started mentioning it, it was met with resistance. Usually along the lines of “The commit message records what I have done”. But, Git is a distributed version control system where there are potentially many places to get changes from. Rather than writing messages that say what you’ve done; consider these messages as the instructions for what applying the commit will do. Rather than having a commit with the title:

Renamed the iVars and removed the common prefix.

Have one like this:

Rename the iVars to remove the common prefix

Which tells someone what applying the commit will do, rather than what you did. Also, if you look at your repository history you will see that the Git generated messages are written in this tense as well - “Merge” not “Merged”, “Rebase” not “Rebased” so writing in the same tense keeps things consistent. It feels strange at first but it does make sense (testimonials available upon application) and eventually becomes natural.

Having said all that - it’s your code, your repository: so set up your own guidelines and stick to them.

If, however, you do decide to go this way then git rebase -i with the reword option would be a good thing to look into.


This comment has been minimized.

Copy link
Owner Author

@Linell Linell commented May 14, 2019

It's been a long time since I made this but the only thing I've changed functionally is that I no longer bother with the (<scope>) portion because, if you're writing decent messages, that should be pretty obvious from your message as a whole and that helps ensure you're able to write a good subject line without using too many characters.

It's also worth noting that, while the template specifically mentions JIRA, Github issues work exactly the same way. You can do it via something as simple as:

Fixes #1001

to close issue number 1001.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment