GitHub Pull Request Tutorial

A pull request in GitHub is the process that lets you tell others about changes you pushed on a GitHub repository. You submit a pull request, and then other people who are interested can review your changes. This gives them the chance to discuss any potential changes to the request and lets them push follow-up comments.

Understanding When GitHub Pull Requests Are Used

There are many reasons why you might use a GitHub pull request. They’re very common in organizations or teams that collaborate with the Shared Repository Model. This model means that everyone shares one repository and uses topic branches to isolate changes and develop features.

It’s common for GitHub open-source projects to rely on pull requests. This is an easy way to manage changes that contributors make. They start the process of a code review and let the project leaders know about the changes. All this can then take place before the changes in the pull request merge with the main branch on GitHub.

Which Projects to Make a GitHub Pull Request On

You may already have a specific change in mind, which is why you want to know how to make a GitHub pull request. Other times, however, you may just want to be involved in GitHub via a pull request. In this case, you need to find a project to contribute to.

The rule of thumb is to choose a project that you actually use. Ideally, you will make a pull request because you’re using a project like normal and notice a bug or think of something that should be added. Instead of contributing to an open-source project for the sake of contributing, keep it natural. If you really want to contribute, then expand your scope and get a coding certificate to begin using other projects. Eventually, you’ll find something to submit a pull request on.

Ask the Developer First

As a common courtesy, take a few minutes to ask the author of the code about a feature you want to add. You could skip this step if the pull request is about a bug. However, if you have an idea for a feature, there’s nothing to say the author hasn’t had the idea. There may be a good reason they haven’t included it, or they might be working on it. Save everyone some time by asking them about it. In many cases, the author might even give you some ideas of what they would like you to include in your planned pull request on GitHub.

Similarly, if you really want to contribute but can’t find a bug or suggest a feature, ask the author if there’s anything you can do to help. This may take the form of a pull request or something else.

Create a Branch for Your Code

Before you start coding to craft your GitHub pull request, create a branch specifically for that code. As a side note, you should also do this with any other specific fix or feature for a project. Choose a name for the branch that makes sense given the change, isn’t too long, and is understandable.

Writing the Code

Now, you can get to crafting the code that will make up your pull request. If you need to learn more, consider taking a coding bootcamp to get a certificate. As you write the code (and the commit), try to keep the style of the project as a whole. For example, if there’s a test suite in the project, write tests for your changes. If it utilizes camelCase variable naming, follow suit.

If you really don’t want to follow the author’s stylistic choices in your pull request, open an issue. This way, you can discuss that with the author. Otherwise, you might accidentally offend the author.

Include a Commit Message for GitHub

Once your code is written, go ahead and include a commitment message. You can find a nice format for a commit message online, with the key categories of a first line, details, and potential bullet points. Remember to keep it short, as it’s better to have multiple commits than one that’s too long.

The best way to make a clean commit is to use vim with your syntax highlight on. This way, you’ll get notifications when you reach the character limit and have enough room for the commit. If you close the issue with your commit, don’t follow the typical trend of including “closes #xx” or “fixes #xx” by the end of the commit. Instead, put it by the end of the pull request description field. This prevents multiple notifications in case of a rebase.

Notes on Rebasing with GitHub

It’s almost a given that you or someone else will catch mistakes or suggest changes when you discuss your pull request with the core team and author. During the rebasing process, take steps to make everything go smoothly on GitHub.

• Try to avoid mistakes in the first presentation of the commit since it would be hard for reviewers to spot a correction in a later commit.
• Use rebasing wisely to do things like compress commits and clean them up. This will help you avoid wasting time.
• You should also try to merge the branches based on the most recent commit of the given branch being merged into. This helps prevent conflicts and delivers a clean history. This might require a bit of rebase work, but you should do it before merging a pull request.

Actually Submitting It

Once you’re done with everything above, you’re ready to actually submit your pull request:

• Open GitHub and select “Fork” on the upper-right corner to save your repo on your GitHub
• Locally clone the repo and open it in your terminal. Then, run a command to make a new branch.
• Add your name on the “list-of-names.md” then commit the changes.
• Push the changes.
• Head to the “compare & pull request” green button on the shared GitHub
• Select “create pull request,” and you’re done.

Expect the team to review it thoroughly but in a calm and respectful manner. Eventually, your contribution will be complete. If you want to learn more before attempting a pull request, you can attend a coding bootcamp to earn a coding certificate.