Software development process must be traceable. How we start from the requirements and how it being converted into a ticket, then in a Pull Request with a set of commits. A set. Not one in the day evening. Why? This post answers.

The more reasonable commits you have, the more traceable git history the project will have. That’s obvious.

But why do ween such “traceable” history of changes? To trace results right in the middle. When we have just 1 commit after year/week/day/etc, we don’t have a full “trace” of developers’ thoughts. Just 0 and 1 state. We can’t get back and take a look at some unfinished code. We can’t check the reason why this code is being changed. It’s not being developed in just one take. But our history we will have only a squashed final one.

That’s why smart people invent VCS, including SVN (2000), Mercurial (2005) and Git (2005).

By committing every reasonable change, we are doing a good service for our project. We can trace every ticket, every requirement till commits we create.

Let’s take a look at l3r8yJ/oop-cop/pull/125. It’s a pull request we managed to merge just today. This one solves this l3r8yJ/oop-cop/issues/85.

How its being done:

This is a traceable development. Thanks to these Git commit messages, we can build a thought line. A reasoning. This is an incremental contribution.

The result is:

  • Each person can take a look at how this ticket being resolved
  • Puzzles being converted into new tickets

So, the more traceable your commits, the more maintainable and transparent is the project. Many incremental commits a day. That’s the way.

Check a few more examples: eo-cqrs/eo-kafka/pull/429:


  • I found an old issue
  • Created a few commits including skeleton, adding/removing object from
  • Reported a broken test with @Disabled + puzzle, as explained here
  • @maxonfjvipon asked me to resolve code duplication inside that task also mentioned
  • I fixed that, requested a re-review
  • @maxonfjvipon approved
  • @yegor256 (an Architect) approved too and @rultor merged