Hands-on with Atomic Commits — Part 2: The Project

J Silva
3 min readJun 9, 2022

--

In this part, we will use a simple API project using layered architecture to demonstrate the use of atomic commits in the real world. Basically we will have a system that has four layers (in a top-down view):

1. HTTP
2. Service
3. Repository
4. Database (data persistence)

The purpose of this article is not to delve into the architecture presented, but to show in practice atomic commit strategies.

Before we start let me tell one important thing, an atomic commit must have only one responsibility (Single Responsibility Principle in SOLID), that is, each commit must be a commit that fixes or implements a functionality and this commit is independent, that is, the files of that commit only respect the functionality that is being made. This means that you should never mix files from different packages in the same commit.

In our project we have four layers, HTTP, services, repositories and database. Each layer should have its own commit and you should never commit all files in a single commit.

remember you were told to use git add -a?
forget it, never use that command again!

Initially our project will be empty containing only a main branch with a README file, as shown in the figure below.

Github repository can be found here.

In my IDE I already have the project ready and what we will do next will be the commits of the files. The important thing to note at this point is that I’ve already done the whole project just for the purpose of demonstrating how the commits will be done, but you can choose to make the commits as you like as long as they are atomic, and when you finish this In this series of articles it will be clear to you that this is a matter of strategy as agreed with your team as the fact that your commits are atomic will help the reviewers a lot, even when the pull requests are bigger.

The appearance of my IDE is shown in the figure below.

As you can see, I have nineteen files to commit, we can do this in two ways using the following strategies:

  1. Divide and conquer strategy: by parts
  2. All in one strategy: self-explained

The commits will be the same in both strategies, the only difference between them is the amount of pull requests you will use.

remember you were told to use git add -a?
forget it, never use that command again!

Next: Hands-on with Atomic Commits — Part 3: All In One Strategy

Previous: Hands-on with Atomic Commits — Part 1: Locating Yourself

--

--

J Silva

+20 years of development experience. Golang Lover. Linux Soldier. Blockchain enthusiast.