Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Further Thoughts on When Not To Squash #17

0cjs opened this issue Aug 21, 2018 · 0 comments

Further Thoughts on When Not To Squash #17

0cjs opened this issue Aug 21, 2018 · 0 comments


Copy link

@0cjs 0cjs commented Aug 21, 2018

I'm happy to see post blog/content/1311-git-squash.rst discussing when and when not to squash since I too don't think it should be an automatic decision. I'm a big fan of rewriting history on dev branches to make things more clear, merge 'insert bug' / 'fix bug' commit pairs, and so on.

But I think there's a more general rule for this that you don't mention: or split commits (before putting them on master) as necessary to make your commits easier to review. So, as examples:

  1. When you have a commit that introduces a bug and a later commit that fixes the bug, squash the latter into the former.
  2. When you are making whitespace changes, formatting changes or refactorings, keep these as separate commits. It's much easier to review (and ascertain correctness of) a refactoring commit followed by a functionality change than it is to do so when it's all squashed into one commit.
  3. If your new functionality is large and can be nicely broken up into separate parts that are easier to review separately, make these separate commits, especially if some of your changes are only distantly related to other changes. (But each individual commit should pass all tests; don't propose a commit that doesn't work until its children are also added.)

I think of a set of commits I'm proposing for master branch as a story I'm telling to the other developers. Make the story as clear as possible, divided up into reasonably small chunks where you can do so. This will make other developers love, rather than hate, reviewing your code.

And when you're bringing code on to master from a PR, consider this. There's nothing more frustrating to me when I try to contribute to a project than to have a half dozen carefully crafted commits, each making a clear and distinct change, squashed into a giant ball of mud.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.