Git commit best practices
I’ve only been using Git and GitHub for a little less than a year now and I can’t think of any other tool that had such a profound impact on the way I write code and develop applications. I wanted to take a moment and share my thoughts on how to manage the git workflow and produce well crafted commit messages.
Make small commits
Let’s say you have two bugs that you just fixed. Each bug fix should produce a separate commit. By doing that you are creating an organized log of commits, which makes it easy for other developers to read and maintain the code base. It is a good practice to push code more often and not end up with a messy repo. Make small commits more frequently and avoid committing large chunks of code. This makes it easy to glance through the commit history and find what you are looking for. It is recommended that the use of git add . and git add -A should be in moderation and instead the focus should be on making frequent commits.
Commit complete and well tested code
Never commit incomplete code. This goes against the concept of committing. If you are working on a large task, try to break it down to smaller assignments and insure that each task is complete. Also, Get in the habit of testing your code prior to the commit stage.
Write good commit messages
Your commit log should tell a story. Therefore, Writing descriptive commit messages keeps your repository well managed and makes it easy to navigate through your commit log. Your commit message should be short, in present tense and explicitly say why you made the change.
Use the imperative style in the subject line
It’s time to stop using bad commit messages like:
- fixed a bug
- changed a few things
- removing method
- more code refactoring
Use the imperative mood instead of past tense style. Writing in the present tense tells someone what applying the commit will do, rather than what you did. It may feel awkward at first to use the imperative style and sometimes it can even be a bit awkward. In his article “How to Write a Git Commit Message”, Chris Beams explains how to easily apply the imperative style:
“A properly formed Git commit subject line should always be able to complete the following sentence:
If applied, this commit will your subject line here ”
If we apply this rule to the bad examples mentioned above, the result will look like this:
- If applied, this commit will fix a bug
- if applied, this commit will remove method
- if applied, this commit will update markup
Use your code editor for long commit messages
It’s easy to rely on using the -m option when your commit message only consists of a subject line. However, it’s a lot easier to use a code editor when you have to write a body. Make sure that the subject line and body are separated with a blank line.
learn to use Git with command line first
If you consider using a Git GUI (a Graphical User Interface that let’s you use git without having to use the command line) as your first version control tool, then you should first take the time to learn to use git from the command line and then later switch to a graphical interface. You should know that developers often like the command line interface and it’s tools and if you don’t know how the command line works or how to use Git inside the command line, you are going to feel like an incomplete professional.
Read the Pro Git book
You should use the book as a resource to learn about different commands and tools that would improves your workflow.