How to create a GitHub pull request (PR)

Being a network engineer, Git is not something that I used to use very frequently before I started messing around with Kubernetes.  It can be a frustrating tool to work with if you don’t know exactly what you’re doing.  And while it tries to help you from cutting yourself, it’s pretty easy to lose code you’ve worked on if you aren’t careful.  On the flip side, once you learn the basics it’s a very awesome tool for all kinds of revision tracking.

While playing around with the newest Kubernetes binaries I noticed a issue with the ‘fluentd-elasticsearch’ add-on in my lab.  After some debugging, I think I found the issue so I’d like to suggest a change to the code to fix it.  This is what’s called a ‘pull request’ or often just a ‘PR’.  A PR means you are submitting a request to ‘pull’ new code into the active repository.  Once your PR is submitted, people have a chance to review and comment on your suggested changes and if everything looks good, it will get pulled into the repository.  So I thought it would be good to document this PR so you can see the process and hopefully you’ll see that it’s really not that hard. 

To start with, we’re going to ‘fork’ the Kubernetes repo.  Forking essentially copies the code into your own repository.  This is done most easily from the GitHub webpage.  Find the repo you want to fork and then click the ‘fork’ button as shown below…

 
When you hit ‘Fork’ Github will tell you that’s it’s copying the code…

And when it’s done, it will put you into your very own copy of the repo.  Notice that you’re looking at the same code, but it’s now under your name…

 
Ok, so now we’re in business.  The first step is to clone your new repo down onto your PC so you can work with the code.  This is done by using the Git ‘clone’ command…

git clone https://github.com/jonlangemak/kubernetes.git

 
Now that we have a local copy of the code, we want to create a branch of the repo to make our changes in. While I don’t think this is required, its certainly best practice so you aren’t working on code in the master branch directly.  So we’ll create our proposed changes in a new branch and add our commits (changes) to that.  Let’s create a branch called ‘fluentd-elasticsearch-kibanafix’

git checkout -b fluentd-elasticsearch-kibanafix

This command creates the branch and automagically switches you to it as shown below…

 
Now all we have to do is make our changes.  In my case, I wish to edit two files.  Let me make those changes quick in the background…  <files change>

The next thing to do is to make sure that Git saw you made some changes.  We can do this by issuing the ‘git status’ command.  The output should look like this…

 
Great!  So it knows what files I changed.  The next step is to add these files to your commit.  As you can see above, Git knows that the files changed, but it tells you that you have not yet staged these files for commit.  To stage them, we need to add them to the commit.  There are a couple ways to do this.  You could add each individual file to the commit, or you could add all the files in the repo to the commit.  I prefer the method of adding all the files just to make sure I didn’t miss one that I changed.  I do that with this command executed in the code repo root…

git add .

 
Perfect, so now it knows that these changes should be part of my commit.  So now we need to commit the changes to our branch.  This is done with this command…

git commit –m <Commit Message>

So now we have committed the code, but we still need to upload the code back to GitHub.  To do this, we push the code to what Git calls a ‘remote’.  In our case, the remote is GitHub.  We can see what the current remotes are by issuing the ‘git remote –v’ command.  In our case, the remote is already set to the where we cloned the code from and is called ‘origin’ by default…

The next step is to actually push the changes back to GitHub.  We can do this with the Git push command…

git push –u origin <local branch name>

When you execute the command, Git will ask you to log into the remote server.  Once you authenticate, it pushes the changes for you back to GitHub.  That’s it!  Now let’s head back to the GitHub website and see what we have.  Head over to your forked repo and you should see something like this…

 
So GitHub knows you just pushed code and it’s giving you the option to create a pull request right on the front page.  Click the ‘Compare & pull request’ button…

 
The top part of the page let’s you make comments about your PR.  This is where you explain why you want to make the change and the actual changes to the code that you implemented.  If you scroll down further, you can see where GitHub does an automatic diff of the code between the master (stuff you forked) and the branch you submitted…

 
Once you review the changes and make sure they are the ones you wanted to make hit the ‘Create Pull Request’ button and you’re all set!

 
So there you have it.  Not so hard right?  Git is like anything else, it takes time and repetition to learn how to use it.  Before you go crazy with pull requests just try using Git and GitHub to track random files.  I use it to track some configuration file for me that I use in the lab and it was certainly good practice on the Git basics.

More to come soon on this topic hopefully!