4 ms·
Depends on the situation entirely. If I see a ton of commits like "fixing formatting" or "oops", I want those squashed away into proper commits. If the change
by warmwaffles 4y ago
Depends on the situation entirely.
If I see a ton of commits like "fixing formatting" or "oops", I want those squashed away into proper commits.
If the changes you make are atomic in their own right and I can check out that commit, compile it, then run tests, and it passes. That's perfect. It works good for git-bisect, but the trick is to get everyone on board in the project to do that.
For public libraries I maintain, it's squash merges all the way. I like a clean history and the ability to check out that commit, compile, test, and run cleanly is perfect.
- giancarlostoro 4y ago> If I see a ton of commits like "fixing formatting" or "oops", I want those squashed away into proper commits. Every team I'm in I strongly advise against such commits honestly. They don't help anyone, I emphasize being able to find things you changed if you need to find them. You can even enforce a format for commits. Funnily enough, I saw a wave of "fixes bug" "now really fixes bug" that got auto rejected by some commitcop utility at a former job, the guy was freaking out cause it wouldnt take all his changes. I guess they wanted to force him to stop doing such awful commit messages. Commit messages should be useful and historically descriptive.
- warmwaffles 4y ago> Every team I'm in I strongly advise against such commits honestly. They don't help anyone, I emphasize being able to find things you changed if you need to find them. You can even enforce a format for commits. Same with me, but people still ignore it.