Request for Review and Merge – Pull Request
Pull Request in GitHub is used to create a request to review changes made on a topic branch and merge it with a main branch (e.g., the master branch). It has nothing to do with the pull command although the naming is similar. To avoid confusion, you can memorize it as a merge request. In GitLab, it is in fact called a merge request.
Before raising a pull request, you need to push an edited branch to a Remote Repository. After pushing the branch, you can ask a reviewer to review and merge with the main branch. You can initiate a pull request on the GitHub website.
For a better understanding, please go through the following practice section.
Practice
Objective:
Learn how the Pull Request operation works
The scenario of this practice is the following
- Developer B works on creating a new feature on a new branch Branch_C, and pushes the code to the Remote Repository
- Developer B raise a pull request to ask Developer A to review and merge the branch to the master branch
- Developer A reviews the code on Branch_C and gives feedback to Developer B
- Developer B modifies the code on Branch_C based on the feedback from Developer A
- Developer A finally approves the change on Branch_C and merges it with the master branch
- Developer B sees Developer A's approval
Note: For practice purposes, we are explaining several iterations between Developer A and Developer B. If you want to simply approve the change and merge the code, you can skip from step 3 onwards on this page and go to the next page.
1. Create a new feature on a new branch
At this step, Developer B creates Branch_C that diverges from the master branch and edits the HTML file as if she's writing code to create a new feature on the branch. Also, make some commits and push Branch_C to the Remote Repository.
Action by Developer B
First, create a new branch Branch_C from the master branch.
git checkout master
git checkout -b Branch_C
Switched to a new branch 'Branch_C'
Edit the HTML file like shown below (add <h1>C1LB</h1> after <!-- Branch C-->).
C1LB indicates the following:
- C – Branch_C
- 1 – 1st commit
- L – Committed in the Local Repository
- B – Committed by Developer B.
<!-- Branch C-->
<h1>C1LB</h1>
<!-- /Branch C-->
Commit the change with the commit message "C1LB" as shown below.
git commit -am "C1LB"
[Branch_C 7510fae] C1LB
1 file changed, 1 insertion(+), 1 deletion(-)
Repeat the same process of editing the file and committing the change twice.
Use C2LB and C3LB for each commit respectively and check the log to see the latest status.
git log --oneline
You can see that there are three new commits on Branch_C.
6fc9649 (HEAD -> Branch_C) C3LB
c33e4e8 C2LB
7510fae C1LB
4e7dbf9 (origin/master, origin/HEAD, master) M3LA
4e1a7d9 M2RA
4b30a1c M1LA
The HTML file status should look like the one below.
<!-- Branch C-->
<h1>C1LB</h1>
<h1>C2LB</h1>
<h1>C3LB</h1>
<!-- /Branch C-->
Next, push Branch_C to the Remote Repository.
git push origin Branch_C
You can see that Branch_C is successfully pushed.
Enumerating objects: 11, done.
:
* [new branch] Branch_C -> Branch_C
Now you can go to the next step.
2. Raise a pull request to ask for a review and merge
In this step, Developer B raises a pull request t
eBook Library
for Web Skill Training