3 ms·
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 a
by 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 agoI 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.