35 Git Best Practices to follow (in 2020)
Today I’m going to reveal 35 of my all-time favourite Git best practices.
These are the same exact Git Best Practices and Advanced Git Tips that I used to boost my productivity …. in short time.
Let’s dive right in…
Don’t have time to read the whole guide right now?
I've created a downloadable pdf with a one-line summary of Git best practices .
Also my all time favourite AFTER technique (to boost your productivity).
Before You Read Git Best Practices, Keep This In Mind…
Most people fail to follow Git best practices for one simple reason:
They try to follow EVERYTHING.
What is the Solution?
Git "AFTER" technique...
I will share my all time favourite AFTER technique in this post.
This simple technique helped me to boost my productivity by 80%.
AFTER technique is simple principle based on Git best practices
35 Git Best Practices
Git Commit Best Practices
#1. Atomic Commit
When you do an atomic commit, you're committing only one change. It might be across multiple files, but it's one single change.
Atomic commit = one commit for one change.
Your commit should be atomic. Each commit should be able to get built.
If any commit is breaking the build, it should be easily reversible.
Also, these commits help other developers to understand better about the project. These commits are documentation for developers.
A commit should be atomic.
#2. Commit Early, Commit Often
If you are done with your atomic task.
Do not wait...
You should commit your changes early and often.
Early commit helps to minimize the risk of conflicts between two concurrent changes.
Additionally, having periodic checkpoints means that you can understand how you broke something.
I prefer to commit early, just after my single change. Frequent commit is one of my favourite Git best practices.
You can commit locally "all the time,” and you need to push when everything is working.
If you do small commits, it allows you to use compelling tools like Git-bisect.
#3. Do Not Commit Generated Files
You should commit your code to your repository.
If you're checking in generated files, you're doing something wrong.
Generated files can not help with your repository size.
So you should not commit anything that can be regenerated.
#4. Do Not Commit Dependencies
The code repository is to hold code.
You should not commit your dependencies into your codebase.
It is not adding any value.
The package manager can manage your project dependencies. It will download them on in each build for you.
#5. Do Not Commit Local Configuration Files
You should not commit your local config files into the source control.
Because config files might hold secrets or personal preferences.
Your config files might contain general information that is specific to your local environment.
Configuration files might change from environment to environment.
For example, QA and Production environment have different configuration files.
#6. Do Not Commit Half (Broken) Code
Are you eager to commit because you need a clean working copy (especially when you are in a hurry?.
You should wait...
You should not commit broken code in the repository before leaving the office at the end of the day.
You can consider Git’s “Stash” feature instead of Git commit.
#7. Test Your Changes Before Committing
It's always good to test your changes before you commit them to your local repository.
Testing before committing adds an extra layer of protection.
If you break your problem into small parts, it will give you a better understanding of the problem.
And help you with testing.
#8. Write Useful Commit Messages
Creating useful commit messages is one of the best things.
A right commit message helps others to understand the code better even without looking at your coding.
When checking at the history of a repository to answer a question, a right commit message becomes very important & helpful.
You should also enforce your standards on commit messages in your team.
Usually, you can use the first line to provide a summary (up to 72 characters) of your change.
#9. Review Your Changes Before Committing
Unit testing is a must, and code review is nice to have things for many developers.
But I love to have both in the workflow.
Quality always pays less in the long term.
And it will not take more than a few minutes if you review your work before committing.
#10. Use The Reference Number With Your Commit
The reference may be an external bug tracker reference number or your VSTS task number or any other.
When you use a reference number with your Git message, it helps in many ways.
- It adds clarity to why you made some changes.
- It helps others to review your code.
#11. Refer A Commit By It's Hash
In Git, a hash is 40 digits log hex-decimal number. Every time a commit is added to a Git repository, a hash string generated.
And in Git, you should use a hash to identify a commit uniquely.
You can view a commit with Git show <hash>
#12. VCS Does Not Substitute For A Good Backup
Your version control is not a backup system.
You still need backups. One is not a replacement for another.
Version control and backups are independent concepts. These both should be used together.
Git Workflow Best Practices
#13. Choose A Workflow
Git offers a lot of flexibility, and there is not any specific workflow for everyone.
Workflow heavily depends on the size of your team and the skill of developers.
You should pick a style that best suits your project and team.
Workflows are the paths for you and your team that describes one crucial thing - How something goes from being undone to done.
#14. Enforce Standards
In Git, having standards will improve three essential things in your repository.
- It will enhance the quality of your commits
- It will enhance the quality of your commits
- The overall code-base quality
It is one of my favorite Git Best Practices.
In addition to the above, team productivity will improve, and you can use powerful commands like Git bisect.
You can enforce the standards by server-side or client-side hooks.
#15. Integrate With External Tools
Communication is the key.
If you increase communication and transparency in your team, it has many advantages.
You can use an external system like Jira, Microsoft Visual Studio Team Services (VSTS), any other arrangements for better communications.
Use external systems are pretty standard stuff, but still a Git best practices.
For example, you can use the reference number of these external systems tasks in your Git commit message. It will increase communication and transparency in the team.
Git Pull Request Best Practices
In this section of Git best practices, I will share core practices for pull requests.
#16. Use Pull Request
Once your working branch is stable with your changes, and you ready for a merge with master. Make a pull request.
It helps others to review your changes. Improve the overall quality. And finally, it helps to make sure only stable cod in going into the master branch.
#17. For One Concern - One Pull Request
When you raise a pull request, make sure it's only and only for one feature.
If a pull request contains only one change, it's easy to review and much faster to get approved. And overall productivity and quality boost.
#18. Do Not Delay With Pull Requests
Pull requests should not be unattended for a long time.
It increases the chances of more conflicts.
So It is essential to review the pull request soon for any merge or to deploy. It will fast and smooth the overall process.
#19. Complete Your Work Before A Pull Request
Tidy up your work and all commits before a pull request.
It's good practice, and at the same time, you do not want to request a half baked food. And it will add no value to review broken code.
So make sure you. Complete your work before the .pull request.
#20. Comments With Your Pull Request
You should use appropriate comments with your pull request for two reasons.
- It guides the reviewers.
- Fast the overall process
Your comment should highlight what and why. (and not how /when)
Git Branches Best Practices
Git is a powerful tool and its one of the biggest advantages is its branching capabilities.
In this section of Git best practices, I will share core practices for Git branches.
#21. Use Branches
What is the crucial feature of git? Gits branches model.
You should use branches. As an example - a new git-branch for a new feature, another git-branch for bug fixes, and so on.
#22. Branch Naming Convention
You should follow a branch naming convention.
It helps to keep your repository organized.
An efficient branch naming convention allows you to keep merge conflicts at a minimum.
#23. Delete Stale Branches
You should delete old branches that are no more in use.
For example - you completed a feature and merged your branch with master. Now you do not need your feature branch.
If you do not delete old branches, you may end up with many stale-branches, and it's become hard to manage.
#24. Keep Your Branches Upto Date
You should make sure you are correctly using pull and push.
You should consistently merge your base branch into your current branch as you work.
It's beneficial if it’s a long-outstanding branch.
This practice will help you to save your time and energy.
Otherwise, you will spend your time in resolving an unnecessary amount of merge conflicts.
#25. Do Not Rewrite History
You should not rewrite history on any shared branch.
If you are rewriting history, you are making life harder for everyone else working on that branch.
#26. Protect Master
What is the most crucial branch in your Git repository?
By protecting the master branch, nobody should be able to make a direct check in to the master or rewrite history for it.
Also, only merge requests should be allowed in master after a code review process.
So no Git push straight to the master branch. It is definately in your list of Git best practices.
#27. Test Before You Push
Test before push is good one, In fact its part of my favorites - AFTER technique.
If you did not test your code and property, it has a knockout effect. You might block the entire development. (actually, it happen)
So it's always worth spending a few minutes to test your code before you push.
Also, you can use the pre-push Git hooks to run tests before pushing code to your remote branch.
Git Best Practices For Small Teams
In this section of Git best practices, I will share additional tips for Git.
#28. Define Code Owners
This practice depends from team to team. You can assign owners for different codebases.
It helps in faster code reviews.
#29. Use Git Ignore
Many developers never use git ignore file. But I used a gitignore file and feel it's power. It's again one of my favorite practice.
You should use a .gitignore file in each repository.
It helps to ignore predefined files and directories like config files, user settings, and other unwanted files.
This file helps to keep your repository clean.
You can choose a relevant template from Gitignore.io to get started quickly.
#30. Use Rebase
Instead of Git merge, you can rebase the feature branch onto the Git-master branch with rebase.
You will get a significant benefit of rebasing - much cleaner project history.
And Second, with Git-rebase, you will get a perfectly linear project history.
#31. Keep Your Repositories Healthy
Git is powerful, and it provides some out of the box tools.
You can use these tools to keep your repository health by performing maintenance tasks occasionally with git-gc and git-prune
Keeping your repo healthy is not only a Git best practices but also important for your organisation.
#32. Use Diff
You should review every single change before you commit.
For example, If you have already added a few changes to staging, you can confirm them before you commit with Git diff like - git diff --staged
It helps you to understand what precisely the new changes are.
#33. Stash Name
Git stash is excellent for storing changes temporarily.
You should use Git stash with a name.
So you can easily keep track of what’s what!
It's straightforward to add a name like this.
Git stash save “Some description of changes."
#34. Tag Your Releases
It is also a good practice - when you make a release,
The main advantages are
You can see when you make a release
Easy to go back early state by looking at the tag
It acts as an additional piece of documentation that can be extremely helpful.
#35. Don’t Mix “Refactoring” With Feature
If you ask me the worse thing new developers do - Refactoring and adding new feature in same commit.
Its simple against git best practices.
You should not mix refactoring with new features.
It is not suitable for many reasons.
- It will increase the chance of having conflicts that might be harder to resolve.
- Your code becomes harder to review:
Overall, productivity will decrease.
So far, I have shared 35 Git best practices.
Now I will share AFTER technique.
Bonus- AFTER technique
At this section of Git best practices, I will share AFTER technique which helped me to boost my productivity within 7 days.
AFTER technique is based on Git Best Practices.
A - Atomic Commits
F - Frequent Commits
T - Test before you push your changes
E - Enforce standards
R - Refactoring is not a new feature.
My all time favorite Git best practices is AFTER technique.
Now I’d like to hear from you:
So from the above "Git best practices" post, what is new new to you?
Or maybe I missed something.
Either way, let me know by leaving a comment below.