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?
The increase-heat-strain
branch was created from the main
branch and a new commit was added “Increase heat strain to 5”.
Before increase-heat-strain
was merged back into main
a new commit (“Increase weight strain to 6”) was added to main
.
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 increase-heat-strain
into main
doesn’t have any merge conflicts because the values were incremented in two different areas.
When merged our PR, 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
The increase-heat-strain
branch should have been brought up to date with main
before merging it into main
.
This could have been handled by switching to the increase-heat-strain
branch and either:
a. Merging main
into the branch (with git merge main
) or
b. Rebasing (with git rebase main
)
Leave a Reply