FREELessons: 24Length: 3.1 hours

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

4.4 Merging Branches

So now that we've created some branches and we've made some commits on those branches. It's time to pull that content back onto the master branch. So we're gonna look at doing that in this screen cast. There are actually two ways that you can do that. The first one is through merging two branches together. And the second is rebasing two branches together. And we'll look at the most basic way of using both of those in the screencast today and see the differences between them. Now before we actually get into this, we're gonna be running that Git Log command to make our little graft several times in this screencast. So I'm just going to make an alias right here on the terminal. I'm just going to alias it to gl, and we're gonna say git log --online --all --graph --decorate, and that's our alias. So now if I just run gl, we get our graph just like that. Here's what we have right now. We've made an experimental branch, we have a bug fix branch, we have a master branch. Master branch has had some commits since those two branches Have had commits on them. And now we wanna bring some of that content back to the main branch. We're gonna start by merging in the bug-fix branch. We're on the master branch. If I run Git Branch, you can see that we are on the master branch. So we're gonna run git merge, and then we're gonna pass it the reference bug-fix-1. So what this is going to do is it's gonna take the current content of the latest commit in the bug-fix-1 branch, and it's gonna merge all that content into our master branch. Now when we merge it actually creates a commit, and as you see, when I hit Enter here we're gonna be taken to our editor to say, what commit message do you want? And it's gonna have a default message there saying, this is a merge commit so I've got Git merge bug-fix-1 the name of the branch and when I hit Enter, you can see we're brought here to an editor. And you can see the suggested messages merge branch bug-fix-1. I'm just gonna stick with merge branch bug-fix-1 for now, so I'm gonna save and quit this and you can see right down here we have merge made. By the recoursor strategy and we've added this fixed up TXT file right there. So this has actually made a commit. If I clear our screen and run our alias again, you can see that right here, I want you to notice. Pay attention to the master branch here, the master branch comes up, this was our last commit on our master branch updated README title, and then this is where our bug fix merge comes in. You can see, so it branches off right there, and then right here, we have a commit that's with the message Merge branch 'bug-fix-1', and this is where these two branches come together. So you see we have this little bubble here, that is the bug fix branch, and then everything merges back together. And we have our single branch once again. So this is what merge has done, we have split our branch off earlier, made some changes on both branches and now we're merging those back together. So the changes we made on the bug fix one branch, are now incorporated into master branch and if we do a list of our files here you do see that we have the fix fix.txt file which is the only change that we made on that bug fix branch. In fact, let me show you this way. I'm gonna run git diff and I'm gonna pass in two hashes in here. Let's see, we want this hash which is the last hash on the master branch before the merge. So I'll put that first, actually, no I want that one second. And I'll put right here, before that, the last hash on the bug fix branch. So now when I hit Enter, you can see there were two differences here, and so as you can see here, this header line was removed, and it was actually changed. We added some content to it down here, and then this line here was removed. Now it was actually added, but because of the view that we're looking at in It's showing up as if it was taking away, but if we just cat out the fixed file, you can see that our content is very much there. So you can run a dif like that just between any two hashes and we will show you the difference between those two commands. So as you saw before, if you run getlog, yes, that merge has actually taken place. So now that that merge has taken place, there's no reason for us to keep that bugfix range around, so I'm just gonna run command. Git branch -d to delete it and we want to delete the bug fix branch1. I'll hit Enter, you can see deleted branch bugfix-1 and now if I clear our screen again and make our graph, you can see that the bubble still shows there. Because that content still exists in our history of our repository. However, notice that there's no reference pointing to this latest commit here, so when we deleted that branch, we didn't actually delete any content, we just deleted a reference that pointed to a commit. Very simple, very clean, and that is how to make a merge. Of course, there's going to be more complex situations where you're going to have conflicts between files where different things were changed and a merge can be a bit more of a messy situation. But, I'd say for most of the cases you're going to run into as a beginner to intermediate user, this is how things are work 99% of the time. Now I mentioned another way of bringing content from one branch to another and that is via a re-base. Now a re-base is a little more complicated but I think you're gonna be able to understand this just fine. So let's do a re-base with the experimental one branch to bring it's content onto the master branch. Take a good look at this graph that we have right here, especially this part here. And I want to point something out to you. We branched with our experimental branch right down here, at updated read me. We made two commits on our experimental branch. Then we made a commit on our master branch, on our bug fix branch, and then we merged those on our master branch. So three commits have happened off of a master branch since we branched off with those two commits that we made in the experimental branch. Now, the way a rebase works is this. The idea of a rebase is it keeps your history much more clean and more linear, and it really does its best to erase any kind of evidence that we ever actually branched at all. The idea is, branches can get kind of messy, especially if you have a lot of people working on a project, maybe they each have a branch, several branches, you could have 15 to 20 branches If you look at some large Git repositories, using a rebase can make things a lot more linear and, well, it doesn't a pretty graph like this, it is a lot more easy to keep track of. So what we're gonna do is we're gonna say git rebase experimental-1, and when I hit Enter, what it's gonna do is it's gonna undo all of the changes that have been made on the master branch, since we branched with the experimental branch. So that means these three commits here are going to be undone. Then it's going to play the changes that we made on the experimental branch one by one onto the master branch. So added a branch to do item and added a date to README. Those will put onto the master branch and then it will replay the these three commits up here back on top of those ones. So you can think about it as interleaving the two commits that we made on experimental branch before we made commits on the master branch. It's gonna stick those back into the master branch where they took place. So I'm gonna hit git rebase here, and I want you to pay attention to that output that we get from it. So notice we have first rewinding head to replay your work on top of it, so it rewinds head right up here all the way back down to here. Then the content form the experimental branch is played on, and then the commits that we made after branching with experimental branch are played back on. So, you can see here applying, fix the bug, and applying, updated readme which are the two commits that we made up here. Now, this is kind of going to do away with our merge commit as you'll see, but the content will still be the same. So now that we've done that, I don't wanna clear the screen because I wanna be able to compare these. So I'm just gonna run Git Log, and as you can see, we have a very linear history. Let's compare these. Up here, the last commit that we made on the master branch, before branching off with experimental branches updated read me. And we can see that we have that right there, but then up here, we have these two commits on the experimental branch. Added a branch to do item, and add a date to README. And those show up right here, right after that last commit on master. Added a branch to do item and add a date to README. And as you can see this is where the head of the experimental one branch is still sitting. Right now the history looks as if we created that experimental one branch at that commit, but we never actually made any commits on the branch so the branch diverted. Actually branched off, next our fix the bug commit was played on, and then we have the updated reamming title commit played on. So as you can see, it's kind of removed our merge commit. That's okay, because all the content is still there, and we actually have a much cleaner history now even though that's the intention. And you're never going to actually depend on a rebase to clean up something that you didn't emerge. However, that just happened to be a side effect of the way we branched and merged in this case. So now I can safely delete our experimental branch because that content has been played onto the master branch. I've deleted that, and now I can clear the screen, run our git log, and you can see that we have a very linear history, just the way we would have had it if we had never actually created any branches at all. But just made that content linearly on out master branch. I want to point out, before I close up this video, that the merge and rebase situations I've shown you here are kind of the ideal case when everything goes properly. Of course, when you're making changes in multiple files on multiple branches and especially if you have multiple people involved in the project, there are gonna be conflicts between things where git doesn't know well, should I use this content from this branch or should I use this content from this branch because these are actually conflicting. And in a future video, we might actually look at a few techniques for dealing with conflicts like that. But as I said, for pretty much 99% of the situations you're gonna run into as a Git beginner and probably intermediate as well, what you've learned in this video is gonna be all you're gonna need to know about branching and rebasing.

Back to the top