Git is a “Version Control System”. The architecture of git is Distributed Version Control which prompts collaborations among users. It is the most used versioning system in the last few years.
People can work with git in a decentralized way so sometimes it will be more complicated, but once we have an understanding of how git works then it will be good if we admire best practices.
By considering that you are at least aware of the commands and usage of the GIT, let me help you to know the best practices to use GIT. I have tried to find out by working with different teams and projects.
Do Commit Often
As we know that someone takes responsibility on their end only if they have something with them likewise if we commit our changes then only git take responsibility for it. If you fail to commit and something goes wrong with code or code gets removed somehow then no one can help you on that. So the best practice is to commit your changes as early as you can.
Always work with own branch
To achieve the above point of Commit regularly, I suggest having your own branch always work with your project. Your own branch can be local or remote. If it’s remote then others may use it but will be good even if it’s remote, there is less chance to use it by others and it will be safe even if you lost data from your machine.
Write proper commit messages
Commit messages are always meaningful and descriptive which helps other users who are working on the repository. This helps people to quickly understand without looking into the commit code. I really like the blog written by Chris Beam about “How to write a git commit message”.
Follow Git Workflow
Workflow is basically a path or a guideline for an efficient way to use Git. There are many workflows available from which you can choose or define your own workflow based on your team size and skills. This will boost the productivity of your team. I like this description about how to choose a workflow.
Always create a habit of creating pull requests for merge on the main branch rather than merge code directly from your branch to the main branch. Pull request helps to review your changes by improving code quality. Pull requests will be based on a small chunk of logic. It should not be with half logic code to give for review. If you have a Pull Request to review then do not delay reviewing it, your delay in reviewing it creates more bad code and it will waste more time.
On every release try to give a tag. It will be good practice when we release new features on the project. Tags are to keep track of the project versions. Tags are also helpful to find out the difference between the 2 releases. By using tags we can easily roll back to previous releases.
In the summary above, there is best git practice called the “AFTER” Technique. This helps to improve productivity and code quality.
A – Atomic Commits
One Commit for one change or we can say commit one and only one thing.
F – Frequent Commits
Any time you complete a part of code that compiles and runs successfully then have to commit it. So commit your change early and often.
T-Test Before You Push / Commit
It is very important to test your code before committing, especially before pushing on the remote.
E – Enforce Standards
There are 2 standards which always need to follow
- Use git Ignore
- Use workflow
R – Refactoring is not a new feature
Refactoring and adding new feature both are different things, so do not mix refactoring with a new feature
Code refactoring is not going to add any more value to the business.
While working with GIT you have to be calm (don’t panic) and need to follow simple predefined workflows which reduce stress and help to maintain your code while working with big or small teams.