re: How I Write Source Control Commit Messages VIEW POST

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

The beauty of providing the card number in your commit message is the ability to reference exactly what was done.

That's a noob mistake to rely on your issue tracker. You can add a reference but the commit should be self-sufficient. If your issue tracker is replaced—and not archived—you will be left with a diff and the message body.


I have yet to see a development organization that would be willing to copy the full context of the ticket/card into a commit message. I'm sure they exist, but based on my own experience I'd think they are a minority. So linking the card/ticket absolutely provides greater context into what the change was trying to achieve, even if the commit itself is nicely squashed and written up.

And yes, if you switch ticket systems you will likely lose the ability to automatically link to those cards. Having done this several times, I've found that it is generally possible to import into the system with the same id/number as the original system. You lose the automatic linking, since each system seems to have a different pattern it expects the number in, but when you see #12345 in a ticket you can still pop open your ticket system and find [12345] or XYZ-12345. The key is whether your org sees the value and finds it worth the extra investment during the migration from ticket system A to B.

In my career, I've seen several source control migrations where we had to make the same call. Is it worth migrating so we keep the original commit messages or should we just start clean with a single "All the changes up to now" commit?


copy the full context of the ticket/card into a commit message

You probably misunderstood me. I just want to deter messages like "feat: close #235".

Is it worth migrating so we keep the original commit messages or should we just start clean with a single "All the changes up to now" commit?

If you really care you will have to rewrite the history.


Whenever possible go for the migration. I work on a product with a 15-years-history and sometimes it helps to know that a feature/"behaviour" was introduced 10 years ago ("it has always been like this") rather than 15 months ago. Good commit messages are really helpful, of course.


Pretty sure the post went on to say that your message should be descriptive by itself too. So it doesn’t sound like they were suggesting we “rely” on the issue tracker, just utilize it.


I find the opposite better. Closing the cards with the commit or merge SHA:
Fixed in c678ads...etc.


I would agree if I wasn't lazy and relied on the auto closing feature of the issue trackers that are properly linked to the repository.


I feel like your comment could have been just as effective without calling me a noob to start. Thanks for the comment though.


I was just warning you because I used to be that noob and it sure was embarrassing to not have foreseen the dependency problem. You will have to experience it for yourself.

I feel like

triggered :)

See that was a more effective argument/starting point than just calling it a noob mistake. Experience, be it my own or someone else's, is a good place to learn.

What did the dependency issue end up being? Right now my cards arent physically linked to the source control, so I am manually using the numbers as a sort of reference point. (We use Microsoft Planner for our cards and VS for source control)


ha, you're probably right. But we become less noob at some things as we learn from our mistakes (errr... experiences?)

In dev world mistakes are experiences as much as bugs are features.
(This one is growing into being my favorite topic on devto)


An issue tracker is an essential tool in development. You should be able to rely on its existence for as long as the history of the source code is relevant. Eventually tools are replaced, but so are commits relegated to history by then.


…but so are commits relegated to history by then.

It seems that you are not using log and blame as much as I do.


Sadly it happens. My last org went through a few kinds of issue trackers. Some of which had licences and would cost money to keep around, so they were ditched. Adding a reference can be super useful, but I feel the commit should speak for itself.

Anyways we ended up using gitlab's issue tracking features, which are quite nice as well.

code of conduct - report abuse