This lesson covers two ways of getting commits from one branch to another: merging and rebasing. You’ll learn what is involved in each method as well as how to decide on which one to use in your projects.
Merging and Rebasing
Merging and Rebasing. Once you’re finally finished with your new feature or whatever the purpose of the branch was, it is time to absorb the changes back into the
master branch. And the two most common ways to do this are merging and rebasing.
When you merge, Git creates a new commit and combines the top checksums of the two branches into one. And if all the commits in the feature branch are ahead of the
master branch, Git will do what’s called a fast-forward merge and place the commits on to the adjoining branch. That’s what’s happening in this diagram.
But what if, say, somebody on our team has made commits to the
master since we started our feature branch? Git will account for this with a new commit that is a combination of the changes. If, however, the same section of the code has been modified, Git will stop the merge and tell you there is a merge conflict.
00:52 It will give you instructions on how to start fixing the issues. So, let’s hop into the console and do a fast-forward merge. Back in the console here. Let’s kind of orient ourselves with the parenthetical.
We know that we’re on the
master branch and if we do
01:12 you can see that we’re on the most recent commit. If you think back to the last video, we put together a feature branch and put a file into it. Let’s merge that branch into this branch.
To do that, we use
git merge and then name the branch, which was
You can see here Git is indicating that it’s a fast-forward merge and that one file has changed and one insertion happened. So, let’s look at
And you can see up at the very top here that
my_new_feature file—that commit’s been added to our
master branch. And if we list the directory,
my_new_feature is now in
master. So that’s a fast-forward merge.
Let’s talk about rebasing. Like we talked about earlier, using
merge creates what’s called a merge commit with all the combined changes of your two merging branches.
This can potentially muddy up project history and sometimes make it difficult to go back and troubleshoot. Using
rebase instead of
merge can make the project history look more natural, like a branch never occurred.
02:25 Rebasing does this by rewinding to what’s called the common ancestor of both branches and then playing it back. It then takes the diff of each branch’s commits and adds those changes to the project history. You will find yourself asking which one is better, which one you should use.
02:43 The answer is neither is better and you should use the one that fits your team and your project. Now, I don’t have a rebase scenario for you in this series, but if you take a look at the Real Python Git and GitHub for Developers article, there’s some great resources in there for websites that will let you learn and work with advanced merges and rebases.
03:07 Regardless of where you fall on merging versus rebasing, I’ll leave you with this excerpt from the Pro Git book—again, available for free on Git’s website. They say, in general, the way to get the best of both worlds is to […] “rebase local changes you’ve made but haven’t shared yet before you push them in order to clean up your story, but never rebase anything you’ve pushed somewhere else.”
Git uses SHA-1 checksums to identify commits. They’re nothing more than unique IDs expressed as hexadecimal numbers such as
Merging two or more branches into one often results in creating a new commit, which becomes the child of the most recent commits in all parent branches. I think that’s what Paul meant by “top checksums.”
It’s useful because commits can be shared across multiple branches without duplication. (They form a directed acyclic graph.)
Great tutorial Paul.
At 3:03 of Merging and Rebasing you mentioned a resource on RP that discussed in further detail merging and rebasing.
I did a search and the only resource I could find was realpython.com/python-git-github-intro/#putting-it-all-together-simple-git-workflow
But when I search page for rebasing there was no resources? realpython.com/python-git-github-intro/#rebasing
I did find this resource which looks pretty awesome. And you did plug the free Pro Git book.
So, between these 2 resources, I’m sure the subject of rebasing will be explained in more detail.
Your explanation was a good primer!
Become a Member to join the conversation.
vincentstclair on Aug. 6, 2020
When you say merging creates a new commit that combines the top checksums of the two branches into one, what does this mean and why is this useful?