A Practical Guide on Understanding Git Best Practices

Introduction

In this post, we will learn about some of Best practices while working in git.

I hope you have seen previous git training posts:

Don’t Do a direct commit in Master branch

Master branch is the default main branch in git. You should have your recently released code in git, which is like a replica of what is live. So that, any bug fix or any features can be built over it.

By directly committing, you are risking any urgent bug fixes. You should create other feature branches, test there and commit to master only when those changes aare ready to go live or went live.

Read more about one of Simplest Git Branching Strategy

Always take a pull before pushing changes

Before pushing your code, always first take a pull from remote branch. This is to make sure that your branch is up to date with the source branch. And, there will be no conflict at the time of push. By taking pull, you might need to resolve conflicts.

git pull origin master

Put restriction in who can commit to your Master or other branch

In git, you can put restriction on who can commit or merge code in your restrctive branches like master or other branch.

For more details see: Protect Git branch

Restrict that at least N number of code reviews are required before merging

Code reviews are most important aspect in managing code. Peer code reviews can discover hidden bugs or issues, and they are very effective. Study shows that almost 70% bugs are caught in code reviews, if done effectively.

For more details, how you can restrict, read Mandatory Code reviews

Do write a good commit message and description

You have written a beautiful code, and developed awesome feature. But, 1 year down the line, when you needed to visit your commit history. You wonder why the hell this commit exists.

A well written commit message always helps.

Clean your Commit History before Merging

When we create a Pull Request (PR), please clean it by git rebase command. This enables you to remove any unimportant commit ids into main branch. Your feature branch might have some commits like correcting typos, fixing compilation error. But, there is no benefit of putting this as commit history. You can merge this commit with other commits.

The idea is to merge unnecessary commit ids into one.

Have a thorough Code Review

Code reviews are very important. Do not blindly merge your PR into main branch. Get it reviewed by your peer. A second eye always helps. You might accidently put some files which you don’t want to commit.

Have a .gitignore File

Its important to have .gitignore file in your project. We might accidently add files which are not intended for commit. We usually have files like credentials, which can accidently get pushed.

Always review your files to push list

Don’t do a blind push. Always review the files which you are committing and pushing. Always have a look at the diff by using git diff. Sometimes, developers put some temporary code change for development which you don’t want to push.