Introduction
It has been commonplace that people are kind of afraid of commiting. It's not rare to see big, heavy changes in one single commit. And this is not good, since it will not be easy to code review.
There are many, many ways to improve commits, and this goes through two simple tips: standardize your commits and create more branches. Let's talk about them a bit.
Standardize your commits
It is very important to have a standard for message commits, because it makes it easier to read, as well as to reuse them. We only need to change specific details, depending on the changes being made.
It works better when there's already a chosen flow, which is generally previously agreed with other team members. There are many options available, and lately I have been using gitmoji.dev as an add-on to them.
Create more branches
Maybe because of subversion, people think that branching may create some overhead on the project. But that is not true. I see branching, along with git messages as part of the documentation. They must explain directly what is being done.
If a feature branch is created and two people are working on that, tasks must be defined and each (sub) branch should be created for each person. Then, one approves the changes of the other and vice-versa.
Conclusion
Regarding the commits, along with standardization, I also like to commit empty changes using git commit --allow-empty to mark the beginning of a branch, or some intermediate and important point. I even commit broken or incomplete code this way!
git commit --allow-empty -m":boom: going to lunch, incomplete code is pending bugfix on feature WorldDomination"
Branching per se may lead to a "branch hell" problem, but only if they are not properly managed. A branch must be created and then, when it's purpouse is reached, the pull request (or merge request) must be created, approved or rejected and them the branch must be deleted.
And that's it. If you have any doubts or suggestions, let me know in the comments below.
Cheers,
Top comments (0)