Skip to main content

Simpler alternative to Conventional Commits

TLDR: Just put the fucking Issue ID in the commit message, you asshat!

I keep reading about Conventional Commits, and I think they are somewhat contrived and over complicate a simple requirement of commits: What context was a change made for. As we all know, information is somewhat useless without context. And I feel the same what about commit messages. And the best context in a commit message a link to the original Ticket in the Issue Tracking system. Most Issue Tracking systems support linking to the SCM, so that you can have a bi-directional link. If you look at an issue you can have a list of SCM changes done for that issue. For example, here is a JIRA issue showing what code change was done for it:

And if I look into my SCM I can see the JIRA issues that were used to make changes:

And the way to do this is to always have the Issue ID in the commit message. That's it. JIRA has this feature, so does Git Hub. That's all you need to do. Every commit message should have the Issue ID in it. So you can follow back as to why a change was done. That's the context. It's pretty useless to me if I look into the SCM history and see shit like:

feat: allow provided config object to extend other configs

It's great that a feature was added, but why was it added? Who requested it? etc etc...

Comments

  1. That's only for your use case. Conventional commits are useful for other reason too, you asshat! For example, they can automatically generate the appropriate version bump for the next publish. Plus some people on small projects don't need issues for every commit, that's just a waste of time in certain cases, you asshat!

    ReplyDelete
    Replies
    1. It’s easier to aggregate discussion on an issue than a commit with most SCMs because you can discuss the feature that a commit is associated with before it’s implemented and after.

      If there’s no issue associated with the commit, the commit is probably not that important, the project is probably not that important or potentially you shouldn’t be doing it depending on your team’s workflow.

      Delete

Post a Comment

Popular posts from this blog

How to get two docker-compose services to talk to each other

Imagine you have two services that are started by two different docker-compose files. And you would like these two services to talk to each other. How can we achieve this? Why would you want to do this in the first place? I had a use-case for this, that's why! The use case was as follows: I have a docker-compose file that contains linux-swag and mysql . These are resources that are not updated very often. So I can start them and forget about them. I have another docker-compose file that contains a Spring Boot application. This application can have different versions (prod, staging, dev). And these version get automatically deployed on each git-push.     The nginx serves HTTPS and reverse-proxies connections to the spring application. The spring application connects to the mysql to read and store stuff. The Secret Sauce The way to do this is with docker-compose networking . You see by default each docker-compse file creates it's own bridge network. So by default, in my exampl

Ubuntu Wireless iwlwifi and Windows 10 Dual Boot

If you have Windows 10 and an Ubuntu Dual boot, this may cause your wireless in Ubuntu to stop working. And the culprit seems to the the 'Fast startup' option in Windows. What you need to do is described here . Make sure that 'Fast startup' is turned off! Otherwise it can be that your iwlwifi doesn't get loaded into the Linux Kernel.