-
-
Save Linell/bd8100c4e04348c7966d to your computer and use it in GitHub Desktop.
| # 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 | |
| # https://github.com/sparkbox/how_to/tree/master/style/git | |
| # --------------------------------------------------------------------------------- | |
| # Jira Issue Processing | |
| # ISSUE_KEY #comment This is a comment | |
| # ISSUE_KEY #done | |
| # --------------------------------------------------------------------------------- |
Linell
commented
Feb 12, 2015
Can you explain or give more examples of "body should be imperative tone".
[Edit: googled around and found this: http://stackoverflow.com/questions/3580013/should-i-use-past-or-present-tense-in-git-commit-messages]
@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 prefixWhich 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.
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.