| > Who's going to police the feature branches to ensure the merges are cleaned up and rebased prior to merge to main? Do what you like in your own branch. Nobody cares. In the case of a high quality maintained project, such as the Linux kernel, it's when you propose to merge something that it gets policed. The reviewers and maintainers won't let in any PR that doesn't meet quality standards; for large PRs that means a sequence of high quality commits. > Of course, my repos use squash merge, so I'd never get that complaint. If you're saying you squash merge into your own repo prior to submitting the merged result as a PR to a repo maintained by others, that works. That _is_ a form of cleaning up prior to upstream merge. As long as it passes review upstream that's fine, even with the Linux kernel. If you are squash merging into your own repo and there's no upstream, you're obviously free to run your project however you like. Squash merges make sense when the merged PR is full of junk that should be deleted, as you described. But in that case, if you have reviewers in the loop, I would argue you are proposing junk for them to review which you will delete afterwards, and that encourages lower quality, more superficial reviews. Why not just squash it down before the pre-merge review instead, if that's what you're proposing to merge anyway? In a high quality, heavily reviewed project like Linux kernel, a PR has carefully curated commits to assist the review, show each step makes sense, and allow cherry-picking, bisecting and reversion later. That's more useful to the project. It'd be a waste to throw that knowledge away with a squash merge as soon as the reviewers have gone through it. |