As shown in Figure 3.8.1, a pull request is made from your origin repository, which must contain your feature branch, to the upstream repository. In the last section, you pushed your feature branch to your origin repository, so you are now ready to make a pull request.
A pull request informs the upstream repository which branch in your fork (origin) repository contains the changes you would like merged into the upstream.
There are a number of different ways to make a pull request in GitHub. In general, they are all equivalent and it won’t matter which one you use. The following steps will walk you through one of those ways.
When you first push a feature branch GitHub assumes that you are likely to make a pull request for it. To make this easy it will automatically display a big green “Compare & pull request” button at the top of the page for your origin repository.
The bar shows the base repository and base branch on the left, the head repository and feature branch on the right. In the middle there is a left-facing arrow indicating that the changes in the head repository and feature branch will be merged into the base repository and base branch.
This bar specifies the repositories and branches that are involved in the pull request. That is, they indicate which branch you are requesting to be pulled from which repository and to which branch in which repository you would like it to be merged.
The terms “Base Repository” and “Head Repository” are generic labels that GitHub uses for the two repositories that are involved in the pull request. Often, and in our case, these two repositories will be your origin repository and the project’s upstream repository. Match the right hand column with either head repository or base repository to indicate which term refers to your origin and which refers to the upstream.
The base is where you want your changes merged into/the repository you created your fork from. The head is where your changes are being pulled from/the branch you pushed to your GitHub account from your local machine.
The information in the gray bar also indicates the branches involved in the pull request. It uses the generic labels of base and compare for these branches. Match the right hand column with either base branch or compare branch to indicate which is “pulled from” or “merged into”.
When a PR with one of these lines is merged into the project the listed ticket from the issue tracker (e.g. 123 in this example) will be closed automatically. Including these lines is very helpful to the project maintainers because then they do not have to remember to go close the associated ticket each time they merge a pull request.
The #123 part of the line should automatically become a link to the issue. If it does not, check to be sure you have entered the information exactly as shown above.
Check the status of your PR and confirm that it can be merged automatically. The status will be listed at the top of the GitHub page below the image from Task 3.8.1.b
In GitHub look at the top left side of the browser window. If it says "forked from" with a link it means you are in your fork instead of the upstream repository. Click that link to go to the upstream repository.
Open that tab. At the bottom of that page will be a diff that shows the changes you have made. This diff shows both the upstream version of the code and your version of the code. It also indicates the changes you have made. The project maintainers will often use this diff to see the details of what you have changed.
The line(s) which contains the change(s) appears twice. Once in red with the old version and once in green with the new version. The change(s) appear in both in bold.
