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.