5 Git practices that will benefit you in long run
Git is one of the most widely used tools among developers today for managing projects. So much so that it has become one of the listed skills on a lot of resumes. And that's fair. Because a lot of organizations use Git as their primary version control system. There are of course different clients used like Github, Bitbucket, etc. But the underlying software is Git.
But, as with any popular tool, there comes a variety of ways for doing the same thing. And these vary across teams. Hence, having a good understanding of best practices, which not only helps you but the whole team is a good attribute to have. Most of the times, these practices are well documented and presented as a training manual for new developers on the team.
In this post, I am listing out some of the best practices I try to follow when working with Git. Of course, we all have different views on the best practices, but these are some rules that have proven to be very helpful to me. So let us get started.
Best git practices
Meaningful Branch Names
This practice is more helpful for your teammates rather than you. As you can guess by the title, it says that we should give meaningful names to our branches. What will that do? Well,
- It will help you keep track of branches when switching between features and fixes.
- It will help your peers get an idea of what you are trying to achieve in that branch.
Imagine someone giving you a pull request for review and the branch name is
bug_fixes. It will waste your time to get the context first and then do the review. Which is not what any teammate wants. Following are some strategies I follow when naming my branches.
Apart from these, every organization has its branch naming strategies documented. If your org has one, please follow those. Trust me, it will save a lot of time for you and your team.
Meaningful Commit Messages
This one is probably the most underrated practice a lot of developers miss out on. This one goes hand in hand with the good branch naming strategy. Adding a meaningful commit message is going to help you in
- Letting your teammates understand the purpose of what you were trying to achieve.
A good commit message looks like
If you want to learn more about writing a good commit message, here are some resources:
Single Purpose Commits
I can't stress enough how much this is important. As developers, we all encounter situations where while fixing a bug, you find another one. Or your feature has larger context across modules.
In such situations, it is advised to have multiple commits with a single purpose. The biggest advantage of this is that you can revert these commits separately in case of any problems.
Other than this,
- It will make your teams code reviews more efficient.
- It will help you track your changes.
Use Git Stash with a message
All developers are familiar with the situation where you are working on something and a high priority bug comes up. Either you have already faced this or going to encounter this situation. Trust me. What do we do in that case?
git stash to the rescue.
git stash regularly will create a long list of stashes where it will be hard for you to pop the changes without any context. At this point, you can use a lesser-known git stash trick.
This will help you keep track of your stashes. And when you want to retrieve a stash, you can do
git stash list and it will show stashes with these messages. If you want a more comprehensive guide on stashing, please refer to Ramakrishna Pattnaik's A practical guide to using the git stash command
Add Pre-commit Checks
Let me tell you a story here. I used work in an organisation where we followed monorepo pattern. One time, I had changed only one property in a component as part of a fix. And thinking that it is such a small change, I committed my changes and pushed the code. It got approved and got merged in the main branch.
At the time of deployment in late night, the test cases failed for that component and deployment broke. There were messages coming from everywhere and I got called in to fix it.
What I did was completely wrong. No justifications there. But this gave our whole team a lesson. This is when we started using pre-commit hooks.
Basically, pre-commit hooks are some checks that run before committing your changes on your changes. And if any of those checks fail, the changes will not be committed.
I can not tell you how important these hooks have performed for us in the long run since then. There are lot of tools available for achieving this. If your team is lacking this practice, I would highly recommend trying it. Trust me it will help.
These are some of the best practices that help me in better maintenance of a project and smooth flow for the entire team. This is not a definitive guide, which you must follow, but if any of these make sense to you, try adopting them. It will definitely help you in the long run. Please share in the comments if you have any suggestions or any specific tips you and your team follow. Until then, Happy Coding!!