Git is a widely-used distributed version control system. And Git best practices play a major role in boosting your team’s code quality and overall productivity.
In this post, I will share my 11 all-time favorite best practices, which you can use now to boost your productivity by up to 80% within five days.
Keep reading …
These 11 Best Practices Known as DIG AFTER RUGBY
#1. Don’t Ignore GitIgnore
This single practice helps you keep your code repository clean by ignoring unwanted files is do not ignore .gitignore file. Using this practice, every commit, push, and pull request you make will be cleaned if you are using an appropriate gitignore file.
You can use local .gitignore or global .gitignore file. The difference in that for global gitignore, you don’t need to commit it to use it. On the other hand, you have to commit your local .gitignore file to use it in your repo.
#2. Atomic Commits
An atomic commit is a commit that is focused on one topic and one topic only. So the idea here is you will break down your task into smaller tasks and handle one more minor task at a given time.
It will help you yo stay focused on the granular task. These atomic commits act as documentation for other developers. They can understand better about the project just with these atomic commits.
#3. Frequent Commit
Before I dive into this best practice, let me ask you a question.
Did you read any rule that says –
Can you not commit more than two times in an hour?
Can you not commit more than ten times a day?
Of course, there is no such rule.
No one is stopping you from making frequent commits. You should commit once you feel you are ready. It helps you and your team to avoid code conflicts up to 85% in your group.
#4. Test Before You Push
Test, before you push, is one of the critical practices. When you commit your changes, you are updating your local repository. And when you make a pull request, you are trying yo update a remote repository.
So if you commit broken code, no one will be affected except you. But when you update the remote repo with your broken code you can block the entire team.
Simple five-minute testing of your code (before your push) can save the entire team’s productivity.
#5. Enforce Standards
If you are working as a part of the team, then it might be possible you or other developers might forget to use the core standards.
What is the Solution? – Enforce Standards.
I will share the single most crucial standard – There must be a message with every commit.
By default, you can commit your changes in git without any message. But if you or someone from your team commit code without any message, will it help you or anyone else? No
You should enforce this standard that there should be a message with every commit. And you can achieve this with the help of Git hooks.
#6. Refactoring is Not Equal to Add a New Feature
Many developers do refactoring their code as part of improvement. That’s fine. But I have noticed many developers start mixing refactoring with a new implementation.
You should not mix refactoring with adding a new feature. It will not help you in any way, and there are two significant drawbacks of combining these two things.
– It will increase the chance of having conflicts.
– Your code becomes harder to review.
But if refactoring is required, then you should do it first and later on add a new feature in the code.
#7. Rewriting History is not Allowed for Public Branches
You should not rewrite history on any shared branch.
If you made some typo in your recent commit, you could easily alter things with the amend option.
In general, you should keep your git history clean. It allows you to find the last working commit and go back to that commit without reverting useful changes.
#8. Use Pull Request
Pull request is useful as it helps to keep your master branch clean, stable, and production-ready. The only commits on master come from pull requests.
There are three main advantages of using a pull request.
- Code Review – Code review helps to maintain a standard coding style across the team and helps team members to gain a better understanding of the codebase.
- Better Stability – Whenever you push the branch, all the continuous integration tests are executed against the codebase.
- Continuous Delivery – As your master branch is stable and production-ready, it helps in continuous delivery.
#9. Go for a Workflow
In simple words, Git Workflow is a recommendation for you. It’s about how to use Git to do some work productively and consistently.
Git is flexible, and you can adopt workflow as per your team requirement. There are many advantages of standardizing your workflow, and the two core benefits of any workflow are as follow –
- Overall It saves your team’s productive time.
- Keep repository, stay clean, and tidy.
#10. Branches Must be Up to Date
Keep your branches up to date. It’s beneficial if it’s a long-outstanding branch.
This best practice will help you and your team to save time. Otherwise, you have to spend time resolving an unnecessary amount of merge conflicts. Testing is important and you must not ignore this.
On the other hand, if you keep your branches up to date, it’s easy to work with any branch and stay up to date with others’ work.
#11. You Should Accept Responsibility for Your Code
In the end, the entire agile team is responsible for the code repository. So we all must accept responsibility for our work.
Remember – When we do sprint, the success of the sprint is the success of every individual team member and if you fail to achieve sprint every team member is responsible.
Summery
These 11 best practices known as DIG AFTER RUGBY
Here is the summary for these best practices
DIG – Do not ignore .gitignore
A – Atomic commit
F – Frequent commit
T – Test before you push
E – Enforce standards.
R – Refactoring is not equal to add a new feature
R – Rewrite history is not allowed for shared branches
U – Use pull request
G – Go for a workflow
B – Branches must be up to date
Y – You should accept responsibility for your code.
“DIG AFTER RUGBY” is all about 11 Git practices to boost your code quality & Overall productivity. Let me know which one is your favorite git best practice.