Conventional Commits – A Necessity?

We've all experienced this: the need to develop an existing project, only to find no way to understand why a feature was implemented as it was, the logic behind the code structure, or the rationale behind a particular module. Similarly, questioning why a piece of code was copied instead of reused.

Recently, we took over a legacy project. Just as we felt we were gaining a grasp of the codebase, the Product Owner requested a new feature – seemingly straightforward, a good opportunity for further project immersion.

Reality hit when the new feature turned out to be an extension of an existing functionality. Unfortunately, the original project lead and developer had left the client's company. Compounding the issue, the Git version control history was uninformative, filled with entries like:

And, of course, numerous files unrelated to the actual requirements were modified.

Ultimately, we delivered. However, dealing with legacy code extended our timeline significantly, impacting the feature's timely and effective implementation. This resulted in increased time and costs for the client – exceeding the original feature's development budget.

Despite past debates and varied opinions within our teams, we've consistently advocated for (link: https://www.conventionalcommits.org text: Conventional Commits rel: external nofollow). While initially a shift for many, requiring careful consideration of categorizing changes by feature or refactoring, the benefits are clear. It's tempting to lump changes together in a single commit, but separating and clearly describing each change and refactoring proves invaluable. This benefits not just future developers, but also ourselves. After a month and multiple feature implementations, recalling the specifics of minor changes becomes challenging.

Beyond traceability, machine-readable information enables meaningful automation. It facilitates automated project versioning via (link: https://semver.org text: Semantic Versioning rel: external nofollow), streamlining processes like package creation and publishing.