Pull Request on GitHub

Creating a Pull Request on GitHub

Git is a distributed version control system that is easily scalable. It’s suitable for projects of all sizes. In the Git ecosystem, project codes are stored in a Git repository. The GitHub website is one of the most popular places to host Git repositories. GitHub offers both free and paid services for Git repo hosting. It makes managing Git repositories significantly easier.

Open-source projects are hosted in public repositories. These projects benefit from community contributions made by developers all over the world through pull requests. In GitHub, a pull request means requesting a project to accept changes made to its code repository.

This guide will demonstrate how to make a pull request to a Git repository on GitHub. 

Prerequisites

The Git client is available for all the major platforms, including all the Linux distributions. Check out the Git download page in order to explore all options. For this guide, we’ll be using Git running on an Ubuntu 20.04 server. Here’s a quick guide on how to install and configure an Ubuntu server.

Git client is directly available from the official Ubuntu repositories. First, install Git using the following command:

sudo apt install

For other Linux distros, check out Git installation for Linux. For a more detailed guide on installing and configuring Git follow this tutorial.

Basic Git Configuration

Let’s start with a handful of Git configurations required to perform the operations:

git config

Next, check the option about the default text editor that Git uses:

git config --global core

Creating Pull Requests on GitHub

We can break down the process of pull requests into the following steps:

Ready? Let’s start!

  • Forking the repo

First, we are assuming that you already have a target repository. Here, we’ll be using the viktor4096/Python. It’s a cloned repository originally from TheAlgorithms/Python. It’s a compilation of various algorithm implementations in Python.

Next, go to the repository page on GitHub. Click the “Fork” button at the top-right corner:

Pull Request on GitHub 4

It’ll fork the repository under your GitHub account. It’s essentially creating a replica of the repo under your account. As it is open-source, you are free to perform changes.

  • Cloning the repo

We need the codes available locally to be able to perform changes. Generally, a GitHub git follows the following URL structure:

In this demonstration, it’s going to be the following link:

In Git terminology, downloading a Git repo is known as cloning. Next, clone the Git repo using the following command:

  • Creating changes
  • Branching

When working on a collaborative project, all the contributors will have different ideas for new features, bug fixes, and others. Some may be implemented with little effort, some may require ongoing support. This is where branching comes in. It’s essentially diverging from the main line of development without messing it up. Branching makes it easier to isolate codes and control what gets implemented into the main project.

Generally, the primary branch of a project repository is called “main”. The code on the main branch is often considered to be deployable for others to use at any time. When branching, it should be based on the main branch. The branch name should not be a deceptive one, for example, “my-branch”. Rather, it should focus on the section of the code you’re working on, for example, “fix-documentation-typos”, “frontend-hook-migration,” etc.

  • Creating a new branch

First, change the current active directory to the Git repo we just cloned:

We’ll be creating a new branch named demo_branch:

After that, change the active branch to the new branch we just created:

In addition, we can create and switch branches from a single command:

If you need to switch back to the main branch, then use the checkout command:

  • Changing the codebase

Finally, the codebase is ready for changes. For demonstration, we will be adding a new file to the project:

To add all the contents under a directory recursively, add the -A flag:

  • Committing Changes

Once the changes are added, it’s time to record these changes by committing them to the repo. Every commit must be associated with a text describing the changes. If it’s a minor change, then we can use single-line messages to commit:

Pull Request on GitHub 3

However, if the change was big enough, then run the commit command without the -m flag. Git will prompt a text file to record the message. Git will use the text editor defined in the configuration to edit the text:

Once the text editor is closed, Git will commit the changes to the repository:

Git

You can verify if the changes were logged properly. Note that the output may differ depending on the level of changes made:

git status

We’re now ready to push the changes to the repo. The changes will be recorded under the current branch. The output of the following command will also report the progression:

These changes will be visible on the GitHub repository webpage. You can toggle the new branch to see the changes made in-browser.

  • Updating local repository

In the case of an open-source GitHub repository, numerous contributors may be working on it. Thus, constant changes will be made. Before making a pull request, your local repository must be updated with the latest codes from the original repository. It helps avoid competing or conflicting codes.

  • Configuring a remote for the fork

The remote repository feature allows collaborating with other developers on a Git project. Each repo should be configured with proper user permissions (read-write or read-only). To sync changes with the original repository, it has to be declared as the upstream repository. Note that this process should be performed only once.

First, check the remote servers currently configured. The -v flag is to display the URLs stored by Git alongside relevant remote short names:

Now, we’ll specify a new remote upstream repo to sync with the fork. It will be the original repository forked from:

git remote add upstream

Next, verify if the remote upstream repo was configured successfully:

git remote -v

  • Syncing the fork

The original repository is configured to be the remote upstream. We’re now ready to sync. Change the current directory to the local repository. Then, run Git fetch:

Pull Request on GitHub 2

In this particular example, the commits to the main branch will be stored in the local branch “upstream/main”.

After that, switch to the main branch of our repository:

Merging the main branches of the original and local repositories will sync all the changes with the original repo. These changes will also be accessible via our local upstream/main branch:

Voila! The forked repo is now up-to-date. Any local changes we made aren’t lost either.

Pull Request

The local repo is now ready to create a pull request. Navigate to the GitHub webpage of the forked repository and click “New pull request”. From the drop-down menus, select the appropriate repositories and the appropriate branch. For example, once you’ve chosen the “main” branch from the original repo and the “demo_branch” from the local repo, it will show something like this:

Pull Request on GitHub 1

Finally, once you have filled in all the information, click the “Create pull request” button. The original maintainers of the repo will decide whether to accept your pull request. They may also ask for revision or editing prior to accepting the pull request.

Final Thoughts

This guide demonstrated how to send a pull request to an open-source software repository.

After creating the pull request, your codebase should remain sharp. If your code was accepted, then congratulations! Alternatively, the repo maintainer may ask to rework your code, so be prepared for that as well.

Happy computing!

About Hark Labs

Software Engineer and enthusiast about new technologies