The web is full of information related to different fields of programming, such as rules for comments writing, classes naming, patterns usage, etc. But not really much about the commit messages writing.
However, you’re already writing decent commit messages. And here are the 10 major rules to follow if you want to level up them to awesome:
- Make the titles always imperative, it should continue the phrase “this commit was made to…”.
- Use present time in your messages.
- Remove unnecessary punctuation marks.
- Use small case (not consistent with Git commands but looks better).
- Place everything in one row.
- Make a single commit for a single change (even really small).
- Point out the path to the file, if it’s not obvious which one has been changed by the commit.
- Never use dates, names and other inappropriate marks.
- Consider your team to define the unified style for commit messages and always follow it.
- Specify the type of commit, as it provides useful context about rest of its title:
- 'feature' — for the new feature adding to a particular level of an application;
- ‘fix' — for a serious bug fixing;
- 'style' — for styling changes and formatting fixes;
- 'refactor' — for refactoring the code of an application;
- 'test' — for everything related to testing;
- 'docs' — for everything related to documentation;
- 'chore' — for regular code maintenance.
Every commit is important. So in Solar Digital we’ve also got a good tradition to use a correspondent emoji to point out the type of each commit.
Emoji works like a flag to ease the understanding of what the specific commit stands for:? for a bug, ?for a disapproved smth, etc. There are various lists of suitable emojis on Github which could be used here.
Having a story in your Git log will make a huge difference in how you and others perceive your project. By taking great care in commit messages, as you do in your code, you will help to increase overall quality. Basically, the most important thing about commit message is being meaningful. Just remember, that when problems appear with a code, the right commit should be easily found — with no pain and in the shortest time.
- Code reviews can hurt. How to avoid the sharp angles in the discussion — How to overcome the common etiquette breaches in code reviews
- Technical debt can be a large trouble if you don’t pay it in time. What’s that — Technical debt. What are my obligations?
- Can you make prototypes faster than anyone? With the new tool, it’s possible — The future of rapid prototyping with the Studio tool