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.