Other developers, especially you-in-two-weeks and you-from-next-year, will thank you for your forethought and verbosity when they run git blame to see why that conditional is there.
Please refer to this link for an in-depth review of the topic: https://chris.beams.io/posts/git-commit/
Useful Tips For A Better Commit Message
- The first line should always be 50 characters or less and it should be followed by a blank line.
-
Never use the -m
/ --message= flag to git commit. It gives you a poor mindset right off the bat as you will feel that you have to fit your commit message into the terminal command, and makes the commit feel more like a one-off argument than a page in history: git commit -m "Fix login bug" -
Answer the following questions:
a. Why is this change necessary?
This question tells reviewers of your pull request what to expect in the commit, allowing them to easily identify and point out unrelated changes.
b. How does it address the issue?
Describe, at a high level, what was done to affect change. "Introduce a red/black tree to increase search speed" or "Remove
, which was causing " are good examples. If your change is obvious, you may be able to omit addressing this question.
c. What side effects does this change have?
This is the most important question to answer, as it can point out problems where you are making too many changes in one commit or branch. One or two bullet points for related changes may be okay, but five or six are likely indicators of a commit that is doing too many things.
Your team should have guidelines and rules-of-thumb for how much can be done in a single commit/branch.
-
Consider making including a link to the issue/story/card in the commit message a standard for your project. Full urls are more useful than issue numbers, as they are more permanent and avoid confusion over which issue tracker it references.
Pro-tip: configure a template so that when using git commit the editor opens with the message template. This way it's easier to keep writing good messages! https://gist.github.com/adeekshith/cd4c95a064977cdc6c50
Pro-tip: configure git so that every time it opens an editor it picks one of your choice. Working with vim or whatever default can be inefficient at times and intimidating to those that don't understand the tool. This way it's easier to write good messages, rebasing and much more! https://help.github.com/articles/associating-text-editors-with-git/
More about commit messages: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html