Thre are more than 35+ Git best practices that are there. And these best practices play a significant role in boosting your productivity and overall code quality.
In this post, I will share my five all-time favorite best practices, which you can use now to boost your productivity by up to 80% within five days.
Keep reading.
These five best practices are known as AFTER technique.
#1. Atomic commits
So the first question what an atomic commit is?
In simple words is a commit that is focused on one task.
Lets first explain atomic tasks with some examples.
You Update a new logo on the site. – it’s an atomic task
You bumped the version of jQuery – it’s a nuclear task
Did you notice something in the above tasks – We are dealing with the one job only.
So the idea with atomic commits is you will break down your task into smaller tasks, and you commit only one atomic task at a given time.
These atomic commits act as documentation for other developers. They can understand better about the project just with these nuclear commits.
#2. Frequent commits
When you break an enormous task into several smaller tasks, it’s obvious that you have to make frequent commits.
Let me ask you a question about commits. 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.
I always encourage developers to commit early and often. Suppose you’re on a distributed team, its best to share your code as much as possible. Your teammates can integrate changes and avoid merge conflicts worry-free.
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.
#3. Test before you push
Software testing is essential. Testing helps to find out hidden issues before we release software to the customer.
And when you push your changes, you are about to share your work with others. And remember, if your code is not able to build, you might block others.
Test, before you push, is one of the best practices. And in general, for testing your changes, there are two ways – Manual way and with automation.
To achieve automation, you can use the pre-receive hook. Git Hooks can be used to execute a script before the changes from a push are written into the repository.
Git hooks provide several ways to hook into the various things that happen. And one of the best ways to execute unit tests before you push and even commit.
#4. 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.
#5. 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.
– Chances of having conflicts will increase.
– 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.
So this is about AFTER technique. Which one is your favorite git best practice? Let me know
