4 ms·

You can do that with squash-merge.

• mattpallissard 3y ago
  But with squash you lose all of the individual commits.
  • BiteCode_dev 3y ago
    That's a pros, not a con. Once something is merged, intermediary steps to get that new thing are no longer interesting. In fact, most rebase workflows squash anyway. In the rare case you have 3 steps in that PR of 23 commits you want to keep, squash it in 3 pieces and merge them.
    • JoeAltmaier 3y ago
      The catch is, does it have to be functional at every step? It may be hard to find checkpoints inside a PR where the changes still produce a useful (testable) product without breaking anything. If it doesn't have to be testable in three pieces, then why break it down? For clarity when reviewing the changes perhaps.
      • alkonaut 3y ago
        The best reason to have it broken up is for posterity to be able to annotate the changes. If there is a 100 line refactor followed by the 10 line actual functional change, then it's a blessing to be able to look at that in isolation when something has gone wrong with it 5 or 10 years later.
    • mattpallissard 3y ago
      Keeping the commit as the unit of change allows you to orchestrate with a single PR. The commit is the change, the PR is the go button. > In the rare case you have 3 steps in that PR of 23 commits I'd have 3 commits in this case. It's not rare at all when you have code, charts, terrform, and scripts housed in a single repo. But even if you're just touching code some changes make sense to go out at the same time. Personally, I feel that the use case for squash is when there are many WIP commits. Those could be avoided with the use of --amend, or --fixup, or cherry picking without a commit, etc.