DEV Community

loading...

Discussion on: How I Write Source Control Commit Messages

Collapse
mouvedia profile image
Info Comment marked as low quality/non-constructive by the community. View code of conduct
G.

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.

Collapse
guneyozsan profile image
Guney Ozsan

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

Collapse
mouvedia profile image
G.

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.

Thread Thread
guneyozsan profile image
Collapse
tarwn profile image
Eli Weinstock-Herman

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?

Collapse
mouvedia profile image
G.

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.

Collapse
erikpischel profile image
Erik Pischel

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.

Collapse
rachelsoderberg profile image
Rachel Soderberg Author

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

Collapse
mouvedia profile image
G.

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 :)

Thread Thread
rachelsoderberg profile image
Rachel Soderberg Author

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)

Collapse
guneyozsan profile image
Guney Ozsan

Aren't we forever noobs being a software dev?

Thread Thread
rachelsoderberg profile image
Rachel Soderberg Author

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

Thread Thread
guneyozsan profile image
Guney Ozsan

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

Collapse
dbanty profile image
Dylan Anthony

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.

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
mouvedia profile image
G.

…but so are commits relegated to history by then.

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

Collapse
colorcodedcode profile image
Robert Schaap

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.