How to Sync a GitHub Fork and Rebase a Pull Request

hey there everyone its Ashley grant here today we're gonna be looking at how to sync a github fork with its upstream repo and then also how to pull those changes into a feature branch that is on your fork this is typically needed when changes have occurred in the upstream repo you've already got a pull request or maybe you haven't but anyway you've been working on something in a branch and you need to pull the the changes from upstream down into your feature branch it's something that when you're starting out with git doesn't seem like the most easy thing to do but genuinely it is once you've done it once or twice it's it it's not too difficult and if you work through this read this tutorial with me you'll understand just how easy it is so let's get started what I've done for our tutorial is I've created two virtual machines and two github accounts we have the upstream virtual machine which has get tutorial - upstream as its github account and then we have the fork virtual machine which has get tutorial - fork what's going to happen during the tutorial is that the upstream account is going to create a new github repo it's gonna push some changes to that repo then our fork account is going to fork that upstream repo it's gonna make its own changes on a feature branch it's going to create a pull request after it's created the pull request our upstream account is going to push some changes up to the upstreams master branch which is going to cause the pull request created by the fork account to no longer be able to be merged no longer be able to be merged automatically and thus we can imagine that the upstream repo maintainer may ask the author of the fork to rebase off of master and so we're going to show you how to do that alright so to start out what's going to happen is to get get tutorial upstream accountant is going to come over here create a new repository for our purposes we're going to call this repository great project we're gonna make it public and we're gonna click on this checkbox here for initialize this repository with a readme this will just make the initial download of the cloning of the repo a little bit simpler by clicking this we get we are here on our upstream repo homepage and we need to go ahead and clone this so we simply copy the HTTPS clone URL come down here I've already got a git bash open I'm gonna type git clone we're gonna paste in that URL press Enter let it do its thing and go ahead and hop into that directory so as part of this tutorial we're going to be doing some simple changes to a file called file one dot txt I'm gonna do most of these changes using the command line just to make life simpler for us in the tutorial but obviously in real life you would use your favorite text editor alright so we'll go ahead and echo edit one from upstream master and put that in to file one dot text now we're gonna add this tell get to track this get ad file one dot txt and we'll go ahead and commit this with an inline message from the command line commit one from upstream master and finally we will go ahead and push this up to the github repo and to do that we just simply say git push and it pushes it up there for us if we hit refresh here we'll see that the the commit message is here we can go look at it and see that the new line has been added and the new file has been added so now then let's go over to our Fork virtual machine we're gonna copy the project URL and paste it into our Fork virtual machine and we're gonna create a fork we're gonna simply gonna come up here in the upper right we're gonna clear click the fork button and that's going to tell github to do its thing create a fork for us should only take a few seconds and once it's down once it's created the fork we're gonna go ahead and do exactly what we did over here on the up string and copy the HTTP clone URL we're gonna bring that down here to our git bash say again git clone paste in that URL and let's go ahead and jump in now before we do anything we need to go ahead and set up this local repo to track the upstream project it's not necessary immediately to do this but if you ever want to sync changes from the upstream repo into your repo this is absolutely necessary it's really easy to do we're gonna say git remote add and call it upstream that's a convention and then what we would do what you would do in real life is you would come and you would click here on the upstream URL and pull that in but since we already have it here we have the upstream page I'm just going to go ahead and click the HTTPS clone URL and paste that in what that's gonna do we can check our remotes but I get remote - V and we'll see that we currently have our original the origin remotes as well as our upstream remotes this will come in handy down the road when we need to sync this repo with the upstream repo all right as I said earlier we need to create a feature branch for our pull request this makes dealing with the pull request very simple github automatically includes any changes on a branch as part of a pull request so it you don't have to to worry about anything it's the best practice go ahead and do this you should probably never do your changes on a fork when you're creating a pull request you should never do those changes within the master branch you should create a of a feature branch to do that we're gonna say get checkout - B and we're gonna call this quite simply future branch and that goes ahead and get create to the branch and puts us in it alright let's go ahead and push some changes into file one dot text so that we have something to do a pull request for so for that we're gonna say echo we're going to say edit one because it's the first edit in our for from fork slash feature branch I'm gonna do two pointy brackets so that echo or so that bash knows to append these changes to the end of the file and say file1 dot txt we go ahead and we look at our file we'll see that we now have two changes at edit one from upstream and it one fruit fork let's go ahead and let get know about these changes let get know to chain chicken to follow these changes and we'll go ahead and commit this change so I'm gonna say omit one from fork slash future branch and now if we look at I'm gonna clear this out and let's look at our git log we have commit one from upstream master and then commit one from fork feature branch alright so now we need to push these changes to github but we also not only do we need to push the commit we need to push the branch and we also need to set up upstream tracking so that that branch is tracked against the local branch this is something that's a little bit complicated to understand but it's very easy to set up to do this we're gonna say git push let's say - - all which tells get to push all Brant all of our local branches to the remote and then we're going to say - you and this is going to push all of our changes and all of our branches and set up upstream tracking on these branches so now as you see here it's set to track remote branch changes from the master from origin but also it created a new branch feature branch on our origin which is our github repo and set that up set up our local branch to track changes from there I'll do a later tutorial to better explain what this all is doing but for now just understand that you just need to say git push - - all - you and it'll make your life very easy whenever it comes time to sync changes from an upstream repo and then push those back to github if we come over here to our github project you'll see that github has pushed out a change to our website saying that a new branch has been created and maybe we'd like to compare and create a pull request in this case yes we do go ahead and load that up we see that it's Auto populated in the commit message and giving us a chance to create the pull request and tells us that this pull request is able to be merged automatically that means that there's no changes in the upstream repo that would preclude get from automatically merging in our changes so we'll go ahead and we'll create that pull request again it tells us that it's able to be merged automatically but we're gonna change that by creating a little bit of trouble if we come here on the upstream virtual machine we see exactly what we see here except that the upstream as the upstream repo owner is able to merge the pull request now imagine that you've created this pull request and the upstream repo owner is going through multiple pull requests and has merged some before yours and some of those changes conflict with files or with code that you've written and there they're gonna need you to merge those changes into your code before they can accept your pull request let's go ahead and simulate that happening let's do this we're gonna say echo edit two from upstream master and push that into file one dot X we're gonna add that to get and we're gonna commit commit one sorry commit to from upstream slash master and now what what's gonna happen is we're gonna push this change up to github and github is automatically going to update both of these pages to let us know that this pull request can no longer be automatically merged because we have conflicting changes that we'll need to work on now that we've done it we see oh we can't merge this automatically so now imagine that you are the the upstream repo maintainer you're gonna say please Lee bass from master and update we see over here we've got the message and as a new user of get you may think be thinking oh no what do I do well I'm here to tell you it's not very difficult at all especially if you keep your master clean you never make changes in master until they've been merged in to the upstream master so I'm gonna go ahead and clear our screen and I am going to pull the changes down from the upstream repo but I'm gonna I'm gonna do a rebase instead of a merge this will just move the pointer forehead pulling the changes and move the pointer forehead to the new to the newest to whatever head is on the upstream we're gonna do this so that we don't create any new check outs in our master so first we need to check out master and we're gonna say get pull - - rebase - tell it to do a rebase instead of a merge we're going to say the upstream master now then what it's done is it's gone ahead we had not previously pulled in these branches from the upstream so it went ahead it pulled those down created new locally tracked branches and did a fast-forward rebase um basically if we look at the log now we'll see that the log on the the fork master and the log on the upstream master are exactly the same the commits are the same and the number of commits are the same all right so we've gone ahead that was easy you know we went ahead because we don't ever make any changes on our master branch the rebase is is easy it's a fast forward rebase just simply do that command and no problem we're good to go things get a little bit more complicated when we move back in to our branch so we're going to get check out feature branch and we are going to for this we will get rebase master now this tells us it gives us a lot of information we're gonna see that it has to patch and a three-way merge merging failed due to conflicts and it tells us that there's a patch file that we need to deal with what we can do to look at what yet has done is we can pull it up in our favorite editor I'm gonna use Adam and we see that git has put the edit from the original up string which there's no conflicts on but then also there are conflicts for the second line we have edit two from upstream master and edit to edit one from fork feature branch and it tells us that the commit message is here so in this case things are pretty simple and in general resolving conflicts with git is simpler than other other source control managers so what I'm gonna do is I'm going to take out what get put and I am going to say well our change was there first so I'm going to do that so this is going to be our merged changes to let get know about and we simply have to save the file okay and then we come over here we say git add and this is a step that a lot of people forget about and causes a lot of confusion we're not necessarily creating the new commit we would think but we still need to let it know that we're ready to go so we say get add file one dot txt and then as get set here when you have resolved the problem run git rebase desk - continue so we'll go ahead and do that get blue beige - - continue alright now if we go ahead and look at our git log we'll see that we've got initial commit commit one commit to commit one that seems wrong but actually it isn't we've we have created a new commit and so when you look here at this commit is de 5 to EB but if we come over here and look in our pull request we'll see that it was one e eight two seven four seven well that's a different commit it has actually rewritten history for us so that that gives us a few problems obviously we need to push these changes up but it's not going to want to let us do that initially so to do that we're gonna have to force it to so we will say git push - - force what this is going to do is push our changes and tell get to ignore any conflicts just go ahead what is on our local machine is to be rewritten over what is on github go ahead and do that and you'll notice that our pull request has automatically been updated we have now that the pull request can be automatically merged and we have a new commit here that's different that's the one we just talked about de v 2e B 8 and we can say I have rebased please consider my changes all right let me see this over here now then as the upstream project upstream repo manager we can go ahead and we'll look at this commit and we'll see oh yeah yes we're happy with the changes this person is made we'll go ahead and come back we'll back up and merge pull request let's say this gives us a chance to create a new commit message because we're actually going to create another commit as we merge in the changes so we'll say merge changes from er 1 ok it has been merged if we come over here on the upstream we'll see that we have a new commit and if we go look at it you'll see that it looks just like this has two parent commits now then over here we have yet again gotten out of sync so what we need to do is check out our master and get pull it tells us we're ahead of origin/master by one commit but we don't care because these check outs are right so we're gonna go ahead and get pull - - me base upstream master and as you saw we were ahead and now we're two steps ahead of this one but we don't care because we're never actually making any edits on our Forks master branch we can go ahead and we can push the changes and we'll see if we come to our downstream fork you'll see that it has commit one from fork feature branch and if we go ahead and do git status we'll see that it's up to date with origin master so if you have any questions about what we've done please don't hesitate to add them in the comments or tweet to me at Ashley M grant all one word I'll be glad to answer anything you have I've been learning this along with you guys and just let me tell you it's it's easy once you start to think about it a little bit differently um the first time I did this it was very very difficult took me nearly half an hour to run through the steps I messed up many many times um but after a little bit of practice it's it's not so hard anymore so anyways I'll talk to you later this has been Ashley great

Channel: Ashley Grant

Views: 17,534

Keywords: git, github, tutorial, Open Source (Software License), Git (Software), GitHub (Website), git fork, git rebase, How-to (Website Category)

Id: M7ZYkjOWr6g

Length: 21min 39sec (1299 seconds)

Published: Sun Mar 01 2015