Commit early, commit often

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, because it makes it easier to read, and also to reuse commit messages, changing only specific details depending on the changes being made. It depends of the chosen flow, which generally is previously agreed with other team members. There are many options available, and lately I have been using gitmoji.dev as a support.

Create more branches

Maybe because of subversion, people think that branching maybe creeate some overhead on the project. But that is not true. I see branching, along with git messages, 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.

Branching per se may lead to a "branch hell" problem, but only if they are not properly managed. A branch must be created, and them, 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,