I’ve worked in several companies from small to large, from consultants to freelance, I’ve worked with teams large and small, and one of the big findings I’ve made is that very few software developers use the Git workflow efficiently.
In the vast majority of companies there is a rule, often taken as absolute truth, that the developer should always make their pull requests small, preferably with just one commit with a single file. It really is much easier to do a code review in a PR that has few lines, but in the real world this is often not possible. So I often see a series of small pull requests that don’t show the real purpose of the change as a whole rather than a PR with atomic commits.
This lack of organization of commits, often due to lack of knowledge of Git and how to use the versioning IDE to your advantage, generate situations that are well known in our daily lives:
1. Pull requests with almost no files so as not to irritate the reviewer (and probably without tests which will irritate the end user even more);
2. Pull requests with a single commit but with a bunch of files inside it, which will definitely annoy the reviewer;
3. Fixes for pull requests made with new commits (which will likely generate noise in the git history);
4. Emoji commits, when the developer decides to put emojis in the commits to look cooler and that shows the extreme of not knowing the importance of commits to the product’s history;
5. Pull requests waiting for reviewers for days, weeks, even months (there’s a rumor that some have gone years without a review, I can say it’s true but I believe it can happen);
6. Reviewers always complaining about the size of pull requests.
To solve all the above situations and increase the productivity and quality of your workflow (and your team) there are atomic commits. But the purpose of this series of articles is not to inform the advantages of atomic commits (you can easily find this information on the internet) but to demystify them by making a project using atomic commits in practice.
If you’ve been through one of the above situations, or if you don’t know what a commit is, or if you’re afraid of making commits and getting complaints from reviewers, or if you’re a reviewer and want to improve your team’s workflow , continue this series by going to part 2.
If you’re already an expert on commits and you think it’s not worth wasting your time reading this series, keep reading anyway and tell me if it was worth it at the end. 😃
