SKIP THIS PART IF YOU HAVE BEEN FOLLOWING THE SERIES
If you are just joining us for this Git and GitHub Series, welcome! This is a miniseries on how to handle most of Git’s tasks, especially in a collaborative setting. To get the most of this, create a bookmark folder called Git Series and save this post to it for reference.
You're invited! Join SheCanCode's Women in Tech Community
Find a supportive network, opportunities, jobs & much more, so you can excel in your tech career.
Let’s Begin
Before I jump into the question of “How to raise a Pull Request?”, I have to discuss why it’s important and where it fits into the grand scheme of things.
Where does raising a PR fit in?
We use Git to manage source control. However, Git is just a tool and the way we use the tool to manage our code is critical. One prominent Git feature we use is branches. In a typical project, we have:
- Master/Main Branch — Where we host the most stable version of code, which is also production ready.
- Development Branch — Usually created from the main branch, and serves as a branch for merging other custom branches like features/fixes/releases branch. This is the branch where developers mainly collaborate on the integrity of the code written before they can merge it into the main branch
This is where raising PRs to a branch comes into play. Imagine a scenario where you create a feature branch off the development branch, and after you complete your changes, the next step is to merge it back into the development branch. To do this, raise a Pull Request to the development branch as the target. Your changes will now be open to other developers to review your code and either approve it or request changes.
So essentially, a PR (Pull Request) is a development process that provides an interactive way of reviewing and discussing code you are requesting to be merged into another branch.
Why is it important?
- To improve the quality of code
- It simplifies receiving feedback on your code from the reviewer
- It’s open and collaborative and can serve as documentation.
Great; now that we have concluded on these two points, let’s move on to another subject!
1. Prerequisite; What needs to happen before a Pull Request?
- First – on your local computer, in the feature/fix/release branch, add and commit all the changes you would like to push to your remote branch.
- Then run git push -u origin feature/BLO-990, if it’s the first time you are pushing to the branch you created locally. Or run git push, if the branch already exists remotely.
- This is the output you might see on your screen. Click on the first link.
Note: The PR target branch requires being different to your branch for it to work. Here, we have feature/BLO-990 → development branch.
2. The Pull Request Process
When you click on the link, it shows you a page where you will need to do a couple of tasks before clicking the CREATE PULL REQUEST button.
This is what it looks like now:
Change base branch
When you raise a PR by default, it goes against the main/master branch, but depending on the branching model used in your workplace, you might want to first merge your changes to the develop/development branch.
Write a descriptive subject and body for your PR
By default, the subject will use your last commit message. In the body, here is a chance to give a descriptive summary of your changes. You can also add screenshots, videos, links, and steps for manual testing etc. It’s a good rule of thumb to give as much detail as possible.
Click on the Create Pull Request button
If the checks ran successfully and there are no merge conflicts, there should be an attractive MERGE PULL REQUEST button shown. Don’t do it! This is where you invite other developers to review your code, so they can approve it. This needs to happen before you can merge it.
Assign Yourself, Tag Reviewers and Optional Labelling
On the right-hand side of your PR you should see a column with the titles Assignees, Reviewers, and Labels. Assign yourself the PR, and then tag another developer to review the PR under Reviewers, and optionally you can add/create a label like pending review or requires review or help wanted.
The Review Process begins
The reviewer normally gets a notification in their inbox to review your PR. To add feedback or modifications, the reviewer comments near the line of code. As the developer, they expect you to reply to the comments or resolve the issue by making the changes requested and pushing again. Normally, a circle icon appears close to the reviewer’s name to notify them you have made recent changes that need another review. You should click on the icon when you are ready for another review.
This process continues until you resolve all discussions.
Merge changes to the Selected Branch
Once a developer approves your changes, you can click on the green, shiny button that says MERGE PULL REQUEST. Then click on CONFIRM MERGE, and this appears. You can decide to discard the branch or keep it. I vote to discard it, to keep things tidy.
BONUS
How to change the BASE Branch of an Existing PR
To do this, follow these steps:
Under your repository name, click Pull requests.
In the “Pull Requests” list, click the pull request you’d like to modify.
Next to the pull request’s title, click Edit.
In the base drop down menu, change it to the branch you would like to compare changes to
Click Change Base
I enjoyed writing this post because it was very practical! I hope you enjoyed reading it too? In the next post, I will be writing about How to Resolve a Merge Conflict.
