1
00:00:01,000 --> 00:00:05,080
When someone wants to review your
pull request, they just click on it.

2
00:00:05,080 --> 00:00:07,780
They'll see the branch
that you want to merge.

3
00:00:07,780 --> 00:00:13,830
They can go to their clone of the repo and
do a git fetch And

4
00:00:13,830 --> 00:00:17,630
your branch the PR is based off of
will be downloaded to their computer.

5
00:00:18,630 --> 00:00:23,600
Then, they can check out the branch,
git checkout add-letters, and

6
00:00:23,600 --> 00:00:26,280
they can see what's changed
between the checked out branch and

7
00:00:26,280 --> 00:00:30,470
another branch with git diff and the name
of the branch they want to compare to.

8
00:00:30,470 --> 00:00:33,440
Most often, they'll want to see
the differences between this branch and

9
00:00:33,440 --> 00:00:37,550
the master branch, so
they'll run git diff master.

10
00:00:37,550 --> 00:00:40,870
This makes it easy to get a feel for
what's changed, and also to look for

11
00:00:40,870 --> 00:00:43,425
mistakes in formatting inconsistencies.

12
00:00:45,080 --> 00:00:49,100
If the project is code for a website or
application, the reviewer may also run

13
00:00:49,100 --> 00:00:55,010
the project's unit tests to ensure they're
all passing, ruby test_decoder.rb.

14
00:00:55,010 --> 00:00:56,620
Looks like everything's passing.

15
00:00:56,620 --> 00:01:00,950
They should also compile and run the app
to ensure it's still working correctly.

16
00:01:00,950 --> 00:01:04,700
When doing so, they may partly rely
on your notes in the pull request for

17
00:01:04,700 --> 00:01:07,220
suggestions on what to test.

18
00:01:07,220 --> 00:01:09,470
It's pretty common for
a reviewer to find one or

19
00:01:09,470 --> 00:01:12,030
more minor issues with the pull request.

20
00:01:12,030 --> 00:01:14,660
If they do,
they'll just go back to the PR's page and

21
00:01:14,660 --> 00:01:16,370
leave a comment with what needs fixing.

22
00:01:17,530 --> 00:01:22,429
In this case, I'm going to point out that
there are merge conflicts with master,

23
00:01:22,429 --> 00:01:26,902
which the original pull request author
is going to wanna fix before merging

24
00:01:26,902 --> 00:01:28,111
the pull requests.

25
00:01:31,324 --> 00:01:35,881
To make changes to a pull request, you go
back to the git repo on your computer, and

26
00:01:35,881 --> 00:01:38,740
check out the topic branch
that you based the PR on.

27
00:01:40,330 --> 00:01:43,350
Then, make one or more commits
with the requested changes and

28
00:01:43,350 --> 00:01:45,840
push them back up to the remote branch.

29
00:01:45,840 --> 00:01:49,100
Pushing the new commits will automatically
update the pull request page,

30
00:01:49,100 --> 00:01:51,900
and the reviewer should receive
a notification as well.

31
00:01:52,900 --> 00:01:56,240
After the reviewer pulls and tests your
changes, they'll either leave another

32
00:01:56,240 --> 00:01:59,540
comment on the pull request with
additional issues to fix, or

33
00:01:59,540 --> 00:02:00,660
they'll approve the PR.

34
00:02:01,930 --> 00:02:03,340
Once the PR is approved,

35
00:02:03,340 --> 00:02:07,070
it's time to merge the PR branch
with the repo's master branch.

36
00:02:07,070 --> 00:02:09,740
We'll wrap up the course by
doing that in the next video.