Git Commit Types And Guidelines
git is getting involved in our daily workflow and committing our changes is the essential commit part of it. In this article, we will experiment with the ways we can maintain a better git history by using some common guidelines and less used ways to commit changes.
Why should we care ?
Now, you will say, come on, we all know how to commit things to git. I know we do, but the question is how efficiently we are doing this.
Let us pick one of our random repo and ask ourselves what changes were introduced in a commit by seeing the commit log. If we can do that you are, congrats, we are already writing a better history. If we can’t, we definitely have a mess of history. Each commit refers to one or more changes as a set and this set should be meaningful. By adding only related changes and writing a better commit message, we will have following benefits –
- We will make our commits portable and reusable.
- When we or someone reviewing our code sees our git history, he will ask fewer questions and will know where to look for the change he needs.
- A clearer git history can help us spot bugs easily.
- In a team, This will can help in identifying who is accountable for what.
Let us consider a scenario, A boss is on fire –
“You commit to master broke the production. You changed 20 files in 5 directories and your commit message says ‘some changes’. Explain it.”
and now you have to look into that commit and entire change-set, fix the production, and now you are on fire.
Okay, this was too much.
How to git commit ?
Most of us know this already but we will look into some less commonly used flags. I will not explain them here in detail as git manual does that job much better than me. I will just present them with their use cases. For a deep dive, look into the git manual .
First of all, There are some common guidelines for writing better commit messages and some awesome people and organizations established and used them for a long time .
- Commits should have a title and optionally a description if things need explanations.
- There should be one blank line between title and description.
- Title should be under 50 characters.
- It avoid useless punctuation.
- It should be in imperative mood or in a mood which describes what the commit will do, not what we did.
- Description should be no longer than 72 character per line.
- Description should explain why these changes are necessary.
This is most widely used and is for when we know that we have added files related to one change.
This can be used when we change multiple files and we are confident that all our changes are related and there is no irrelevant change.
This is fit for the situations were we have multiple unrelated changes in a single file and we want to add some part of it to the commit. These parts are called hunks.
By using this we can modify last commit. This can be useful when we accidentally committed some unrelated or private information or we missed some files that are related.
This can be useful when we did something wrong a few commits back. For example, missed files etc. The changes need to be made and staged and then the commit hash of the faulty commit should be supplied. Please note that this does not let us modify the original commit message.
This should be followed by a rebase supplied with hash of the commit just before the faulty commit.
This can be used instead of fixup when we need to modify the commit message too and same as previous, this also need to be followed by a rebase supplied with hash of the commit before the faulty commit.
I hope this helps you writing a better git history for future you and others.