Now we've learned how to create branches, right? But eventually you need to merge that branch back into master, presumably to push to production, right? And we've learned that we can use git merge for that. Nothing but a recap at this point. But, as it turns out, you actually have a different option as well, and both of them have their uses. Another way to handle this is by using what we call rebasing. Or in other words, git rebase, and then you specify the branch. Now, how are these different from one another? And mostly, it's kind of hard to explain, actually. So what I think we'll do to demonstrate that answer is actually just dive in and try this out. I'm going to make a directory called git-rebasing and cd into that. Next, I will initialize git. And then let's just echo and create an index.txt file and add that to the staging area. And finally, git commit with

git rebasing and cd into that. Next, I will initialize git. And then let's just echo and create an index.txt file and add that to the staging area. And finally, git commit with start project or whatever. So now if I do a git log, sure enough, we can see that represented. And in fact, we're going to be doing git log a lot. So I'll show you something. You could say git log and add the option --oneline, and this will show all of your commits only as one line. So it's a nice way to get a quick overview of all of your commits, especially when you have a bunch. But then we can also add --graph. Now, in this case, it's not going to make any difference whatsoever. However, when you do create more branches and you merge them in, you can actually represent those changes sort of like a line graph. And that's what this allows for. It's pretty useful. So since we're going to be using this quite a bit, I'm going to turn this into an alias called l.

those changes sort of like a line graph. And that's what this allows for. It's pretty useful. So since we're going to be using this quite a bit, I'm going to turn this into an alias called l. And we'll make that equal to the most recent commands. Okay, so now I can just type l to get that spit out. Cool. All right. So if I list my files, of course, we have that one file. Let's imagine that we're checking out a new branch, and it'll be a bug fix, a hot fix, a feature. It doesn't matter. We'll just call this feature/new. However, before committing to this, let's go back to the master branch and then add something else. Now, remember back to that back to the future analogy I used a few videos ago. When we checked out a new branch, we sort of skewed into an alternate timeline, so to speak. So if you can think in your head of two lines moving parallel to one another, and the commits you make on that left line will not currently affect

skewed into an alternate timeline, so to speak. So if you can think in your head of two lines moving parallel to one another, and the commits you make on that left line will not currently affect anything on the right side. Okay, so let's go ahead and add something else, like an about.txt file. And we'll add that and git commit. And remember, I'm writing these commands out by hand. Don't forget to use the aliases. In real life, I would use aliases for everything, and it's really so much faster for you. Okay, work on about page. And if I now do a git log, we can see two commits represented here, and of course two files. But if we check out our feature, and we do a listing of the files, naturally, we only see the one, right? And if I log that, remember, it's a different line, and it doesn't see any of the commits in the other timeline. So now we're going to work on some feature. And I'm going to represent this feature once again.

remember, it's a different line, and it doesn't see any of the commits in the other timeline. So now we're going to work on some feature. And I'm going to represent this feature once again by adding a single file like this. If I do a git status, I can add that and git commit with work on feature. And then let's do even a second one. Feature 2, save that to feature2.txt, git add, git commit, further, work on feature. And remember, this would be a description of whatever it is you actually did. Okay, so I do a git log here. We can see three of those. I can use my alias. That looks great. I go back to my master branch, and once again, I'm just drilling this into you. None of the changes on our feature branch are represented here. But now we're at a point where we want to merge the changes. So we learned a couple videos ago to use the git merge tool. Let's see what that might look like. And just as a reminder again, take a look at how our

point where we want to merge the changes. So we learned a couple videos ago to use the git merge tool. Let's see what that might look like. And just as a reminder again, take a look at how our log appears. And then we will say git merge feature new. And in this case, there should be no collisions whatsoever. I will save that. And now if we do a git log, sure enough, we can see the first and the second commit we performed, as well as the merge commit itself that brought everything back together. Now let's do the ll command to show the graph. And this is what I meant. Now, because we have merges, you can actually see how that took place. So you can see right around here is where we created a new branch. And then notice the star represents the current pointer or the head. Well, we worked on an about page, and then we made a commit on the branch, and then we made another commit on our feature branch. And then ultimately,

pointer or the head. Well, we worked on an about page, and then we made a commit on the branch, and then we made another commit on our feature branch. And then ultimately, we merged everything back in represented by that backslash into master. Okay, so in plenty of situations, that's perfectly fine. It's a very simple solution. However, especially you'll find this when contributing to open source projects. For example, if you view any kind of Laravel PR, you very likely might see a maintainer say, please rebase this for me. Now what they're sort of saying here is, I want you to rewrite the history to make your commit log that much cleaner looking, because they don't want it to look this sloppy. So here's what that might look like. I'm going to once again, if we do a git log, let's reset everything back to how it was before. So I will copy that and do a git reset --hard. Remember, be careful with this. You should only

like. I'm going to once again, if we do a git log, let's reset everything back to how it was before. So I will copy that and do a git reset --hard. Remember, be careful with this. You should only really do this when working locally, and it hasn't been shared with anyone else. Okay, so now if I do a git log, we can see that. If we go back to our feature branch, we can see, of course, what we had at that point. This time, we're going to do it a little bit differently. We're going to say git rebase master. Now before we run this, I just want you to understand at a high level exactly what it does. It essentially takes, let's do a git log, it takes any unique commits on your current branch, meaning commits that are not already on the other branch. So in effect, well this one, that's on master, right? But then we skewed into a new branch and we added two new commits. So we're going to grab these and sort of save them to a temporary location, and then reapply them as if you just did

master, right? But then we skewed into a new branch and we added two new commits. So we're going to grab these and sort of save them to a temporary location, and then reapply them as if you just did a fresh git checkout branch today. Does that make sense? It's kind of hard to explain. It's almost like we take all the commits on a branch, in this case we have two, and then we play them over and on top of the master branch, the most recent commit as of today on the master branch. We just play these on top of it, and that way we get a very clean sequential commit history. All right, I know that's confusing, so let's just see it in action. git rebase master. Okay, so take a look exactly what's happening here. Rewinding HEAD to replay your work on top of it. That's exactly what I'm talking about. We find the common ancestor between the master branch and the feature branch, which was that very first commit we made. And then we take the unique commits on the feature branch

talking about. We find the common ancestor between the master branch and the feature branch, which was that very first commit we made. And then we take the unique commits on the feature branch and we apply those on top of the latest most recent commit of the master branch. So take a look. If I do a git log, we'll notice that we start the project and then we created a branch, right? But then still on the master branch we added a commit, and then on the feature branch we added a feature and another feature. Notice how these are on top of the latest change of the master branch. And this is exactly what gives us a very clean commit history. So now I'm going to check out master. I'm going to do a git log here. And remember, we've done a git rebase, but we haven't yet merged in the changes. But when we do, you'll see that it's basically a fast forward. It's very seamless. git merge our feature. There we go. And because everything syncs up perfectly,

haven't yet merged in the changes. But when we do, you'll see that it's basically a fast forward. It's very seamless. git merge our feature. There we go. And because everything syncs up perfectly, we just do a fast forward or we change the pointer. Okay, so now I do a git log again. And this time, think about it. Before when we used git merge, we could see that whole graph of how we created a branch and we made a bunch of changes and then we merged back into master. This time, look how much cleaner it is. So if you ever contribute to an open source project and they want you to rebase all of your commits for the master branch, this is exactly what they're referring to.