How to create a pull request on GitHub

Cecelia Martinez - Dec 28 '20 - - Dev Community

You should have already saved and committed your changes locally before pushing them to GitHub and creating a pull request.

How to push changes to GitHub

Git connects our local repository to the remote repository in GitHub by keeping track of the remote URL. This is the link that allows us to push our changes. We can see what remote URL Git has for our project by running:

git remote show origin

This will show the URL of the connected repository, as well as what branches are being tracked remotely and locally.

You’ll notice that your current branch, the new one we created with our git checkout -b <branch-name> command, is not on the list. This is because the local branch is not yet connected to the remote repository.

We can initiate the push with the command:

git push origin <branch-name>

By pushing our changes, Git will essentially send a message to the GitHub repository (managed by the remote URL) with the changes and the new branch information. GitHub will automatically create the new branch and track the corresponding changes. The origin refers to the remote URL (which is why we ran git remote show origin earlier) and the branch name is the destination for the changes.

It’s important to note that pushing changes will push to whatever branch name you pass with the command. Make sure you pass the correct branch name so you do not accidentally push your changes directly to a main branch. In most cases, there will be protections against this, but as a best practice, confirm your branch name whenever pushing changes.

If you try to make an unauthorized push, you will receive an error message. You may also get an error message if your local branch is no longer aligned with the remote branch. This can happen if multiple people are working on the same branch at the same time.

If the push is successful, you will see a message in your console stating you can open a pull request using the given link. You can use this URL or visit the repository in GitHub directly in your browser to initiate the request.

How to initiate a pull request

Now that our changes are on GitHub, we can create our pull request. There are a few different ways to do this -- you can use the GitHub website, the GitHub Desktop application, or the GitHub CLI.

We’ll walk through creating a pull request on the GitHub website. If you visit the repository in GitHub shortly after pushing your changes, you’ll see a yellow banner prompting you to compare changes and start a pull request. You can click this banner to start the pull request process. The vast majority of the time, I’ll use this banner.

screenshot of pull request banner on GitHub

If there is no banner because I haven’t recently pushed changes, I prefer to initiate a pull request from the branches page. This helps me ensure I’m starting the request from the correct branch.

From the repository, click the branches list to navigate to the branches page.

screenshot of Code page on GitHub repository with red border around the branches icon

Here, you can initiate a pull request for any branch that has not yet been merged.

screenshot of branches page on GitHub

Find the branch with your pushed changes and click the ‘New pull request’ button. This will take you to the ‘Open a pull request’ screen.

Breakdown of the pull request page

screenshot of the open pull request page on GitHub with four sections outlined in red. The first section is the branch comparison header. The second section is the main content area. The third section is the sidebar. The fourth section is a second main content area.

Section 1 shows what branches are under comparison. It also will check if the branches can automatically be merged. This does not mean that your pull request can be automatically approved. It means that GitHub has compared the branches and did not find any merge conflicts. It’s best practice to resolve any merge conflicts before submitting a pull request.

Section 2 is where you fill out the content of your pull request, including the title and comment. A well-written pull request is critical to ensuring the reviewer can understand your code and its purpose. Typically organizations will use a Pull Request Template outlining what is required before submitting.

If there is not a pull request template, review the project’s Contributing Guide for any formatting requirements. You can also check out these resources on writing pull requests:

Section 3 is a sidebar with additional information about the pull request. This sidebar appears even after the pull request is created. Here is where you can assign a reviewer, add a label, and adjust other fields associated with the project, such as milestones or linked issues. You may not see all of the options in the screenshot, depending on what options or add-ons are enabled in the GitHub project.

Finally, Section 4 shows the content of the pull request. Here is where you’ll see all the commits you’ve made, what files were changed and the comparison of the changes (called a diff), as well as any comments or other contributors. You’ll want to review this section and validate that the commits and changes are correct.

How to submit a pull request

Screenshot of the 'Create pull request' button

Once you have written the pull request, you can submit using the green “Create pull request” button. If you click the drop-down arrow instead, you have the option to Create draft pull request. This feature allows you to create a pull request that is not yet ready for review. You can then continue to make commits until the pull request is ready. Read more about draft pull requests here.

Once you’ve created the pull request, it’s ready for review! You can read more about status checks and pull request reviews in the GitHub documentation.

Not every pull request process will go smoothly. You may (and will) run into authentication issues, merge conflicts, or need to revert changes. GitHub documentation is excellent for troubleshooting, and remember that Google is your best friend when facing issues.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .