[cdaven]

When picking a git workflow, you should start with your system's and your team's requirements in mind. Don't just copy git-flow or GitHub's simplified version.

Not every team or system uses pull/merge requests at all. Some do pull requests to the development branch, and to master when releasing a new version.

In some teams, code review is the bottleneck, and a developer may have to create a new branch from a PR to keep developing while waiting for code review, then create a second PR that builds on top of the first.

This last workflow is the main reason why I'm opposed to squashing PRs. It just doesn't work.

Also, squashing my carefully composed commits with individual references to DevOps backlog items is insulting.

[throwaw20221107]

>merging a sequence of PRs from same branch is bad if you squash

For me in this scenario, merging `main` w/ squash commit back into PR2 branch after PR1 gets merged works here.

As an aside — if code review is the bottleneck, it's probably not a huge investment to do some git fenangling to get the above to merge cleanly.

But I don't see how this use case is a dealbreaker or even specific to squash...? Won't you have to incorporate/merge other devs' changes to `main` back into PR2 anyhow, regardless of whether PR1 was a squash, rebase, or full history?