5 ms·

I used to think commit messages were important. Now I don't, or more specifically I believe the importance should be shifted to ticket titles. In the workflow

I used to think commit messages were important. Now I don't, or more specifically I believe the importance should be shifted to ticket titles. In the workflow I was introduced to all commits backing a PR get squashed and merged with the commit message for that merge being the ticket number and title of the ticket the PR resolves. This creates an incredibly clean commit history that is easy to trace back to tickets and their associated work items (like product docs). It also frees coders from any burden of writing good messages as they progress.

flerchin 4y ago
I prefer this workflow too. Only issue is if we move to a different ticket tracking software.
- stinos 4y ago
  Well, and finding out what the message #345 really means. I use file/line history a lot, it gets really useless with ticket numbers only. Yes, one could automate that to fetch the ticket description and display it. But the ticket description doesn't match the commit. It might for a simple bug report, but it doesnt at all for a bunch fine grained commits which together build up towards implementing a new feature. Might depend on the line of work, but having been there and done that: nevermore.
programmarchy 4y ago
Both are important, imo. Writing good commits is useful for “showing your work” and breaking things down into steps. For example if I need to refactor a component when building a new feature, then I do it in a separate commit. Makes it easy to spin out a separate PR if necessary, and helps a reader understand why the refactor was necessary by looking at the next commit diff. You can still write “fix” and “wip” commits locally, as long as you rebase them before you push your branch.
- avgcorrection 4y ago
  I also think that more commits when doing refactors help with history tracing once file renames get involved. It can be real head-scratcher to try to trace a function back through some commit that introduces a new feature + a whole module refactor. Even with “follow”.
nicolaslem 4y ago
There are a few issues with this approach: - It becomes harder to change the issue tracking software. I used to work for a company that went through a few bug trackers, resulting in tons of older commits referencing an inaccessible bug tracker. - It forces developers to switch from their IDE or git blame to another tool when doing code archeology. The last thing I personally want when trying to understand some code is more context switch. - Not all commits have an associated issue. I sometimes stumble upon problems in the code that I fix straight away. Writing a good commit message explaining the reason is important because otherwise the context is lost.
- Izkata 4y ago
  Yep, mine is on its third bug tracker since I started (maybe more from before then), and third version control system. All the old cases are lost, but the repositories get imported to the next one and retain all their old commit messages.
brightball 4y ago
Sounds like the approach that Gitlab advocates.
ElijahLynn 4y ago
Yup, squash and merge is THE way to go. I've tasted the good life. I always tie a commit back to a ticket and go to the ticket/issue for context with squash and merge. There is so much rich discussion in it that commit messages don't compare.
ElijahLynn 4y ago
Yup, squash and merge is THE way to go. I've tasted the good life. I always tie a commit back to a ticket and go to the ticket/issue for context with squash and merge. There is so much rich discussion in it that commit messages don't compare. This approach when merging in the GH UI, puts the ticket number in the merged commit (not a merge commit though). And the biggest advantage of this approach is there is NEVER a "revert the revert" situation when dealing with reverting. So easy and clean to revert because you aren't reverting a merge commit. I get that "we can't change issue tracking software" but that is just something you gotta live with, and the advantages of squash and merge far outweigh this "possibility".
sillysaurusx 4y ago
For what it’s worth, I hate squashed commits. I can’t count the number of times that I wanted to know the source of one specific change, only to be redirected at a git diff with thousands of lines of changes. Ridiculous. That defeats the point of source control, which is partly to aid future readers, not merely track changes. I’m happy your workflow works nicely for you, but I hope the mindset goes away. Personally, I think it’s important to force push over your “bad commit” when it happens. That way you don’t generate dozens of WIP commits, and there’s no need to squash. But sometimes WIP commits are fine to let through. They inform other devs about what you’re experimenting with.
- philote 4y ago
  I feel that if you have thousands of lines of changes in one squashed commit, you're not breaking down work enough. IMO, each feature or bugfix should be on its own branch, and then all the commits from that branch get squashed during the merge to a develop/release branch or to the main branch. If merging to a develop/release branch first, then merges from there to main do not get squashed.
avgcorrection 4y ago
Something-something indirection. You’re just saying that messages (or: what and why things happened to the code) should be moved out of the repository and into the issue tracker. This is like me saying that wiki articles aren’t important… because we don’t use a wiki for documentation and just commit the docs in the repository. Yeah, sure. But most of your interlocutors were probably more concerned with the fact that things needed to be documented, somehow.

flerchin 4y ago

I prefer this workflow too. Only issue is if we move to a different ticket tracking software.

stinos 4y ago
Well, and finding out what the message #345 really means. I use file/line history a lot, it gets really useless with ticket numbers only. Yes, one could automate that to fetch the ticket description and display it. But the ticket description doesn't match the commit. It might for a simple bug report, but it doesnt at all for a bunch fine grained commits which together build up towards implementing a new feature. Might depend on the line of work, but having been there and done that: nevermore.

programmarchy 4y ago

Both are important, imo. Writing good commits is useful for “showing your work” and breaking things down into steps. For example if I need to refactor a component when building a new feature, then I do it in a separate commit. Makes it easy to spin out a separate PR if necessary, and helps a reader understand why the refactor was necessary by looking at the next commit diff. You can still write “fix” and “wip” commits locally, as long as you rebase them before you push your branch.

avgcorrection 4y ago
I also think that more commits when doing refactors help with history tracing once file renames get involved. It can be real head-scratcher to try to trace a function back through some commit that introduces a new feature + a whole module refactor. Even with “follow”.

nicolaslem 4y ago

There are a few issues with this approach: - It becomes harder to change the issue tracking software. I used to work for a company that went through a few bug trackers, resulting in tons of older commits referencing an inaccessible bug tracker. - It forces developers to switch from their IDE or git blame to another tool when doing code archeology. The last thing I personally want when trying to understand some code is more context switch. - Not all commits have an associated issue. I sometimes stumble upon problems in the code that I fix straight away. Writing a good commit message explaining the reason is important because otherwise the context is lost.

Izkata 4y ago
Yep, mine is on its third bug tracker since I started (maybe more from before then), and third version control system. All the old cases are lost, but the repositories get imported to the next one and retain all their old commit messages.

brightball 4y ago

Sounds like the approach that Gitlab advocates.

ElijahLynn 4y ago

Yup, squash and merge is THE way to go. I've tasted the good life. I always tie a commit back to a ticket and go to the ticket/issue for context with squash and merge. There is so much rich discussion in it that commit messages don't compare. This approach when merging in the GH UI, puts the ticket number in the merged commit (not a merge commit though). And the biggest advantage of this approach is there is NEVER a "revert the revert" situation when dealing with reverting. So easy and clean to revert because you aren't reverting a merge commit. I get that "we can't change issue tracking software" but that is just something you gotta live with, and the advantages of squash and merge far outweigh this "possibility".

sillysaurusx 4y ago

For what it’s worth, I hate squashed commits. I can’t count the number of times that I wanted to know the source of one specific change, only to be redirected at a git diff with thousands of lines of changes. Ridiculous. That defeats the point of source control, which is partly to aid future readers, not merely track changes. I’m happy your workflow works nicely for you, but I hope the mindset goes away. Personally, I think it’s important to force push over your “bad commit” when it happens. That way you don’t generate dozens of WIP commits, and there’s no need to squash. But sometimes WIP commits are fine to let through. They inform other devs about what you’re experimenting with.

philote 4y ago
I feel that if you have thousands of lines of changes in one squashed commit, you're not breaking down work enough. IMO, each feature or bugfix should be on its own branch, and then all the commits from that branch get squashed during the merge to a develop/release branch or to the main branch. If merging to a develop/release branch first, then merges from there to main do not get squashed.

avgcorrection 4y ago

Something-something indirection. You’re just saying that messages (or: what and why things happened to the code) should be moved out of the repository and into the issue tracker. This is like me saying that wiki articles aren’t important… because we don’t use a wiki for documentation and just commit the docs in the repository. Yeah, sure. But most of your interlocutors were probably more concerned with the fact that things needed to be documented, somehow.