git

You are currently browsing articles tagged git.

So what happens when you submit a PR, but then you want to change it?  After reviewing my proposed changes from my last post, it was decided that I should take a different approach.  The changes I needed to make weren’t substantial, and were in the same spirit as the initial PR, so I decided that updating made more sense then starting over.  All you have to do is update the code and push another commit to the branch.  Let’s assume we’ve made the changes we want to our code again.  Let’s verify that Git sees these updates…

image 
Yep – Looks good so far.  Now we need to add these files to the commit just like last time…

image 
So now the files are ready to be committed, let’s go ahead and make a commit…

image 
Perfect – So now let’s check and see if our remote (GitHub) is still defined…

image 
All looking good – So now all we need to do is push the commit…

image

Let’s go check out our PR on GitHub and check the status…

image 
Nice!  So the code update to our branch automatically got pulled into the PR we already filed.  So we’re all done!

On the next Git post, I’ll talk about the process of squashing commits.

Tags:

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…

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

image

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…

image 
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…

image 
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’

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

image 
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…

image 
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…

image 
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…

image

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…

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

image

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…

image 
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…

image 
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…

image 
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!

image 
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!

Tags: