I usually study on my own by reading O’reilly/No Starch Press books and googling.

Honestly there weren’t any friends or acquaintances that were interested in systems programming.

Until now, I’ve never had a chance to send a pull request.

If you’re in my shoes, and a situation where you need to send a pull request rises it can be a bit frightening and intimidating.

Especially if the maintainer is an expert in that field.

You might get worried if the coded you send might screw up their repository.

Don’t be afraid because even if you’re code has some flaws, the maintainer can close your pr if the project is hosted on github.

GitHub has a short youtube video, on their channel worth watching.

Hitesh Choudhary an indian youtuber does a good job explaining as well.

I’ll make a short summary of Hitesh’s video.

If you’re sending a pull request to an open source project, you’ll need to fork the project first.

You can fork the repo by clicking on the Create a new fork button.

You’ll always need to make a fork which is a copy of the repo because you don’t want to mess up the original repository in any case.

Now you can git clone the forked repository which your account has.

Then run git status to check which branch your own.

You shouldn’t alter the master/main branch in any cases.

To do so you’ll have to create a branch and modify the code there, if the code is good then the maintainer will merge your branch to the master/main branch.

You can use git checkout -b to create a new branch.

The string you pass after git checkout -b will be the name of the new branch.

The same actions are taken, from here on modify the files you want to edit.

Then run the everyday git commands used locally git add, git commit.

Before pushing Hitesh suggests that you should run git remote -v and git branch.

When you’ve double checked your modifications run git push origin branch_name.

Then to finish the pull request you’ll go to your github account where the forked repo is and click Compare & pull request.

The final steps are to Add a title and Add a description.

Hitesh insists that you should spend a lot of time when adding a title/description because these are the sentences that the maintainer must read.

It’s good practice to write concisely so that the maintainer doesn’t have trouble reading your pull request.

Clicking the green Create pull request button will open a pull request to the original repo.

Hitesh’s method to send a pull request is good, but it’s more focused for people who’ll only send a pull request once.

If you’re hoping to contribute multiple times, the following method is recommended.

You won’t be the only contributor in most cases, while you’re working on a certain feature many others will send a pull request as well.

If you’re a couple commits behind, you’ll have to first get in sync with original repo to do so run git remote add upstream and pass the url of the git repo.

stackoverflow has a nice explanation on this.

git remote add upstream

Checkout of the master/main branch.

git checkout master/main

git fetch upstream will download the diffs from the local and remote repository.

git fetch upstream

stackoverflow has a detailed explanation on git fetch upstream.

git reset --hard upstream/master will sync the master branch from your local repository to the remote repository’s master branch.

git reset --hard upstream/master

Again, stackoverflow has great answers regarding this here and here.

From here you can checkout and create a branch and commit as we did above.

If you have plenty of experience in git you can also replace the pull request part you usually do on github with the gh command.

Sadly, I’m not that proficient with the gh command so this is where I’ll wrap up.

If I get more comfortable with using gh from the terminal I’ll add extend the post.