Next I’ll move onto merging the second pull request. Just like the previous one, I first inspect the checks and code contributed and request modifications to any errors I’ve noted until all checks are passing.
Rob actually spotted and corrected the sneaky error in the instructions so the PR passed all checks straight away. However, I’m now left with another blocker to merging the pull request, a merge conflict!
Merge conflicts happen when you merge branches that have competing commits, and Git needs your help to decide which changes to incorporate in the final merge.
In the case of our second PR, the conflict arises from the fact that line 2 of the
pythoncalculator/__init__.py file has been edited. However, the first PR, which has now been merged into
main, also committed an edit to that exact line which Rob’s branch doesn’t know about (the merge of the first PR happened after Rob made his branch off the
main). This has resulted in a merge conflict that git doesn’t know how to deal with and needs our help!
Because the conflict is a simple one, we are able to resolve it on GitHub. For more complex conflicts you may need to pull the branch down and resolve locally.
Click on Resolve conflicts to initiate the process.
This opens a text editor panel showing you any files that have conflicts (in our case
pythoncalculator/__init__.py) and highlights the lines of conflicting code as well as their origin.
In this text editor, we can edit the file to tell git what we want to do with the conflicting code. We want to keep both
import statements so in this case, all we need to do is delete the lines containing source indicator notation.
Our resolved file should similar to the one below when we’re done (they may vary depending on which issues were contributed in each of the first two pull requests).
When we’re happy with our file we click on Mark as resolved
Finally, to commit our changes to the 2nd PR branch (in this case the
divide branch), we the click
and follow through to completion.
As noted, the merge commit will be associated with the person who resolved the conflict (in this case the project owner).
Now all that’s left is to submit an approving review and merge.
First we submit the approving pull request review which is now added PR conversation next to .
Note a couple more things:
Once the approving review has been submitted and all checks are passing, the PR is ready to be merged!
Merge pull request
and follow through to completion. Go ahead and also delete the PR branch (in this case
divide) to keep the repo tidy.
Note that the special keyword
Closes in combination with the issue number (
#4) automatically closed issue number 4.
If that wasn’t the case for your PR, go ahead and close the issue manually.
Go ahead and follow the same processes (reviewing and asking for corrections where required and resolving merge conflicts) for any remaining pull requests.