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

This strategy consists of making one pull request for with all atomic commits performed. As we’ve made our architecture layered and fully decoupled, it will be very easy to implement atomic commits per package created.

We will have eight atomic commits, one commit for each layer and one more commit for the end to end tests, another for the entities package, another for the main and, finally, other for the root files. Then we will have:

1. One commit to the database package
2. One commit to the repositories package
3. One commit to the services package
4. One commit to the HTTP package
5. One commit to the tests package
6. One commit to the entities package
7. One commit to the main package
8. One commit to the root files

For our sake, this strategy is more easy to the developers, and we need to create only one pull request with theses atomic commits.

Let’s get our hands dirty from now on. For the first step, we will perform the steps below:

1. Create a commit for the entities package
2. Create a commit for the database package
3. Create a commit for the repositories package
4. Create a commit for the services package
5. Create a commit for the HTTP package
6. Create a commit for the tests package
7. Create a commit for the main package
8. Create a commit for the root files
9. Push to our repository
10. Create a pull request

Creating a commit for each package

First things first, you need to create a branch to avoid make a push to the main branch. Let’s create the ac-1-all-in-one branch.

See the figure below and notice that the files staged are those related only to the entities package (only one file out of the nineteen).

Also note that the commit message is simple and objective that clearly informs the intent of the commit. If you are using an IDE to create your commits you can commit the staged files (in my IDE I simple type CTRL+ENTER) but if you want to use the command line you can run the commands in the figure below.

Now we will create the atomic commit for the database package.

One more for the repositories package.

See that as you submit the files, the numbers of the remaining ones decrease. Let’s commit the service package now.

Now we will create the atomic commit for the HTTP package.

And the tests package.

We’re almost there, let’s commit the main package.

And last but not least, the root files.

Pushing the atomic commits to our repository

As can be seen in the figure above, we have no more files to commit so we can push all atomic commits to our repository. To do this we use the command below.

Creating a pull request

To create a pull request we can use the link generated by the push itself (https://github.com/jmsilvadev/atomics-commits-aio/pull/new/ac-1-all-in-one) or go to github and create there. I will click on the link because it is much faster and simpler.

The figure below will appear and we need to contextualize it to help reviewers, this part is very important and should not be ignored or overlooked, always put simple and objective information.

After click in the blue button our pull request is created as we will see the figure below.

Let’s now see how our pull request is, notice that there is only one pull request with all the commits inside it.

And that’s it, we finish with the all-in-one strategy, and some points can be observed with this strategy:

1. It’s easier for developers because they don’t need to create multiple branches and pull requests
2. The order of commits matters and helps reviewers a lot as we will see later in this series of articles
3. Although we have many files in a single pull request, because we used atomic commits, we will show you how to review this pull request without overloading the reviewers, after all as reviewers we also need to learn to use the tools in our favor. We will see this later in our series.

Now you have a choice to make, continue the standard sequence of the series going to the next part that deals with the divide and conquer strategy or you can jump to the code review part, after all, being in the real world, we are developers and code reviewers and we need to analyze both sides. It’s up to you.

The repository used in this article can be found here.

Jump to: Hands-on with Atomic Commits — Part 6: Code Review

Next: Hands-on with Atomic Commits — Part 4: Divide and Conquer Strategy

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