A Pull Request (PR) should always be up to date with the branch into which it is being merged. Another way of saying this is you should be able to merge your PR as a fast-forward merge (even if you decide not to do a fast-forward merge).
The Danger of Merging a PR that is Not Up To Date
If your PR is not up to date, you may get unexpected results after your merge.
Example of a Dangerous PR
I’ve created a GitHub repository, salcode/catastrophic-pr, which contains one PR.
If you check out the
main branch, you’ll find everything looks good.
If you check out the PR branch (
increase-heat-strain), you’ll find everything looks good.
If you merge the PR, you’ll find the code fails catastrophically.
How Did this Happen?
increase-heat-strain branch was created from the
main branch and a new commit was added “Increase heat strain to 5”.
increase-heat-strain was merged back into
main a new commit (“Increase weight strain to 6”) was added to
The result is the
main branch is still at a safe level (with “Increase weight strain to 6” added) and the
increase-heat-branch is a safe level (because it does not have “Increase weigh strain to 6”).
Our PR to merge
main doesn’t have any merge conflicts because the values were incremented in two different areas.
When our PR is merged, a merge commit (rather than a fast-forward commit) is created. The merge commit brings both branches together, so while each branch only had one of the incrementing commits – after our merge we now have both incrementing commits (“Increase heat strain to 5” and “Increase weight strain to 6”).
How it Should Have Been Handled
increase-heat-strain branch should have been brought up to date with
main before merging it into
This could have been handled by switching to the
increase-heat-strain branch and either:
main into the branch (with
git merge main) or
b. Rebasing (with
git rebase main)