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.
Join us and get access to thousands of tutorials and a community of expert Pythonistas.
This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.
Hint: You can adjust the default video playback speed in your account settings.
Hint: You can set your subtitle preferences in your account settings.
Sorry! Looks like there’s an issue with video playback 🙁 This might be due to a temporary outage or because of a configuration issue with your browser. Please refer to our video player troubleshooting guide for assistance.
Merging and Rebasing
00:00
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.
00:15
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.
00:33
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.
01:06
We know that we’re on the master branch and if we do git log,
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.
01:28
To do that, we use git merge and then name the branch, which was my_new_feature.
01:37
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 git log.
01:48
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.
02:03
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.
02:12
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.”
Bartosz Zaczyński RP Team on Aug. 6, 2020
Git uses SHA-1 checksums to identify commits. They’re nothing more than unique IDs expressed as hexadecimal numbers such as a7f0b04.
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.)
Doug Ouverson on Nov. 2, 2020
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
Kind regards,
Doug Ouverson on Nov. 2, 2020
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?