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:
|
1 |
sudo apt install git -y |
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:
|
1 |
git config --global user.name "<name>" |
|
1 |
git config --global user.email "<email>" |
Next, check the option about the default text editor that Git uses:
|
1 |
git config --global core.editor “<editor>” |
Creating Pull Requests on GitHub
We can break down the process of pull requests into the following steps:
Ready? Let’s start!
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:
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.
We need the codes available locally to be able to perform changes. Generally, a GitHub git follows the following URL structure:
|
1 |
https://github.com/<username>/<repo>.git |
In this demonstration, it’s going to be the following link:
|
1 |
https://github.com/rubyrosemony/Python.git |
In Git terminology, downloading a Git repo is known as cloning. Next, clone the Git repo using the following command:
|
1 |
git clone https://github.com/rubyrosemony/Python.git |
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.
First, change the current active directory to the Git repo we just cloned:
|
1 |
cd <repo_dir> |
We’ll be creating a new branch named demo_branch:
|
1 |
git branch demo_branch |
After that, change the active branch to the new branch we just created:
|
1 |
git checkout demo_branch |
In addition, we can create and switch branches from a single command:
|
1 |
git checkout -b demo_branch |
If you need to switch back to the main branch, then use the checkout command:
|
1 |
git checkout main |
Finally, the codebase is ready for changes. For demonstration, we will be adding a new file to the project:
|
1 |
git add <file> |
To add all the contents under a directory recursively, add the -A flag:
|
1 |
git add -A <dir_path> |
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:
|
1 |
git commit -m “<short_message>” |
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:
|
1 |
git commit |
Once the text editor is closed, Git will commit the changes to the repository:
You can verify if the changes were logged properly. Note that the output may differ depending on the level of changes made:
|
1 |
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:
|
1 |
git push --set-upstream origin demo_branch |
These changes will be visible on the GitHub repository webpage. You can toggle the new branch to see the changes made in-browser.
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.
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:
|
1 |
git remote -v |
Now, we’ll specify a new remote upstream repo to sync with the fork. It will be the original repository forked from:
|
1 |
git remote add upstream https://github.com/viktor4096/Python.git |
Next, verify if the remote upstream repo was configured successfully:
|
1 |
git remote -v |
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:
|
1 |
git fetch upstream |
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:
|
1 |
git checkout main |
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:
|
1 |
git merge upstream/main |
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:
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!
- How To Enable, Create and Use the .htaccess File: A Tutorial - March 8, 2023
- An Overview of Queries in MySQL - October 28, 2022
- Introduction to Cookies: Understanding and Working with JavaScript Cookies - October 25, 2022
- An Overview of Data Types in Ruby - October 24, 2022
- The Architecture of Iptables and Netfilter - October 10, 2022