Add section on stacking pull requests to Pull Requests guide

[Elliot Winkler]

If you have a set of changes that you need to split up into separate stages, and some of those stages are dependent on each other, you'll need to create PRs that depend on each other. There's some specific advice around creating stacked pull requests. Specifically,

• keep all PRs in the stack except the first in draft (because of the next point)
• you never want to merge a PR that's not the first in the stack into another that's also not the first — when the first PR is merged, you need to rebase all other PRs

[Jongsun Suh]

As each PR is merged, the remaining PRs need to be rebased.

• It helps if merges with main are minimized in all of the PRs (especially the first one). Each merge potentially adds redundant commits in the remaining PRs and it can be difficult to sort through the resulting commit history containing duplicates of parent PR commit ranges that need to be removed, interspersed with commits from the current PR that need to be preserved.
• If using vim for rebasing, the command :<start-line>, <end-line>s/pick/drop is useful for discarding ranges of parent PR commits.
• In the interest of ensuring that the reviewed PR state is not corrupted, after rebasing, do not push the new local branch state immediately. Instead, merge the remote branch into the local branch before running git push --force.
  • Use this shell command: git merge --squash <remote-repo>/$(git branch --show-current).
  • In case of merge conflicts (meaning something in the rebase process mutated the local branch's state), accept incoming for all. The remote branch is the source of truth.