A project’s long-term success is tightly coupled by its maintainability. A clean and well crafted source control history is one of the most important and powerful tools when it comes to maintain projects.
In this document, I will try to provide some recommendations to help us build and keep a clean source control history and make life easier for both our future selves and whoever might inherit and maintain your codebase.
The simplest building block of the source control history is the individual commits. As the commits get better, your source control history gets healthier, the project becomes easier to maintain and develop, which contributes a lot to the project’s success.
A good commit is an atomic set of changes, documented with a well-written commit message.
Make atomic commits
An atomic commit is a logically separated set of changes. Each set of change contains a single block of work that tackles a single task.
Give some thought into your changes and try to divide them into logical chunks of work, each addressing a single operations.
If you can, make your commits digestible; for example, don’t code for a whole week on five different bugs and then submit all of your changes in a massive commit:
1 Fix issues with single sign-on, header layout and another irrelevant module
Try to split your work into at least one commit per bug, with well-written commit messages. This will make it easier to review the changes and pull out or revert one of the change sets later if needed:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 commit a023bac42 Author: Mehmet Seckin <email@example.com> Date: Fri Jan 01 00:00:00 1970 -0000 Enable single sign-on for XYZ context Fixes: #123 --- commit 0c2cda12 Author: Mehmet Seckin <firstname.lastname@example.org> Date: Fri Jan 02 00:00:00 1970 -0000 Improve header layout Moved the navbar towards the top of the page to prevent the logo from disappearing in responsive mode. Fixes: #456 --- commit 10dcb332 Author: Mehmet Seckin <email@example.com> Date: Fri Jan 03 00:00:00 1970 -0000 Add plug-in support for XYZ module Completes: #789
Write good commit messages
There are some well-established conventions as to what makes a good commit message. The following example shows the idiomatic format and sections of a good commit message:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Summarize changes in around 50 characters or less More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together. Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain them. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here If you use an issue tracker, put references to them at the bottom, like this: Resolves: #123 See also: #456, #789
Here are some rules of thumb:
Treat the first line of your commit message as the Subject Line
The first line of your commit message should be treated like the subject line of an e-mail message.
This should summarise the changes in a short, descriptive sentence.
Start with a capital letter
The subject line should be capitalised, for example;
1 Fix file format and indentation
Keep it short - about 50 characters or less
50 characters isn’t an absolute limit, but it forces the author to think about the message and try to summarise it as clearly as possible.
If you’re having a hard time summarizing, you might be committing too many changes at once. Always try to make atomic commits.
Most git platforms are aware of this convention and will display a truncated version of your subject line if it’s longer than it supposed to be.
Use imperative mood in the subject line
Git itself uses imperative whenever it creates a commit, for example if you use
git merge, you will see a commit message like the following:
1 Merge branch 'myfeature' into 'develop'
So when you write your commit messages in the imperative, you’re following Git’s own built-in conventions, which increases consistency across the source control history. For example:
1 2 3 4 5 Refactor XYZ to improve readability Update README file Remove deprecated methods Merge 'feat/abc' into 'develop' Release v1.0.0
is easier to follow than the following log:
1 2 3 4 5 Refactoring XYZ to improve readability README file has been updated Removal of deprecated methods Merge 'feat/abc' into 'develop' Released v1.0.0
Do not end the subject line with a period
Ending wih a period is unnecessary in subject lines. Besides, the period eats a precious character from the 50 character limit.
1 Configure Kerberos authentication
instead of this:
1 Configure Kerberos authentication.
Add a body to explain the context and details of your change
Not every commit message requires a subject and a body. Some commits can be as simple as:
1 Correct typo in README file
There is no need to say anything more. If the reader wants to know what was the typo, they can take a look at the change.
However, sometimes your commit needs a bit of explanation or context. In this case, add details of your change after your subject line. Try to explain the context and reason of the change. For example:
1 2 3 4 5 Re-authenticate user with admin scope The X action requires the user to have elevated privileges. This commit adds functionality to request the necessary privileges and perform the action subsequently.
Separate the body from the subject line with a blank line
git revert generates the following:
1 2 3 Revert "Add the thing with the stuff" This reverts commit cc87791524aedd593cff5a74532befe7ab69ce9d.
Use the body to explain what and why instead of how
Code is generally self explanatory about how a change was made. Focus on documenting the problem your solution and why is it the best way to tackle the problem in the message, instead of the implementation details of your solution.
For example, do this:
1 2 3 4 5 Clear the token cache when a new session starts The cached tokens were being re-used by the browser which resulted in token renewal errors between sessions. Clearing the token cache avoids the futile effort by the browser to renew the previous session.
Instead of this:
1 2 3 Clear the token cache when a new session starts Call `OAuth2UserManager.TokenCache.Clear()` to clear the token cache.
Add references to tasks or bugs at the end of the body
Drop a reference to the related work item to make it much easier to track the cause of the change. This is especially good when the git platform is capable of automatically associating the referenced work item as it also helps with changelogs.
The Pull Requests are an important part of the source control history, because this is the place where a particular change is documented, explained, reviewed and refined.
Keep Pull Requests as small as possible
The more changes in a pull request, the harder to understand it, and the longer it takes to review it.
Break down your work into multiple pieces of logically separate and independent pull requests to ease the review process, catch bugs early and reduce code smell.
Apply single responsibility principle
The single responsibility principle is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.
Just like classes and modules, pull requests should do only one thing. Before submitting a PR for review, try applying the principle of single responsibility. If this code is doing more than one thing, break it into other Pull Requests.
The Pull Request title should be short and self-explanatory
The title should be sufficient to understand what is being changed. For example:
- Add single sign-on support for X
- Improve registration error handling process
The description should contain as much detail as possible
- Describe what has changed.
- Explain why has the change been made.
- Clearly define how the change was implemented
- Use screenshots, code snippets and other resources to demonstrate the changes.
This is especially helpful if the Pull Requests are merged into the mainstream via a squash merge, in which case your PR title and description will automatically form a good commit message.
This document is heavily inspired from the following articles: