- Hey, I'm Cameron McKenzie.
I'm the editor in chief @theserverside.com.
And you can follow me on Twitter @Cameronmcnz.
I want to talk to you right now about doing a rebase
and specifically doing rebase of the master to a branch.
That's a little bit unique, you don't typically do that.
And it's fraught with challenges.
Rebasing is fraught with challenges
because you're playing with your git commit history,
but doing it with master,
not always a great idea.
Usually instead of rebasing master onto a branch,
you probably want to rebase the branch onto master.
And I have a tutorial for doing that as well,
but in this case,
this is what I'm gonna do with my scenario.
As you can see,
I've got a master branch here
with commits A, B, C, D and E in them,
and at commit number C the develop branch splits off
and the develop branch has a commit called F and G in it.
Just to keep things really simple,
I've named the files that I put into each commit
after the commit name.
So a.html, b.html and c.html.
Those are in both the master and the develop branch because,
well, we don't split off until commit number C,
commit number D and E create files,
d and e .html in the master branch.
And you can see over here in the master branch.
The master branch has D and E
as far as the develop branch goes,
it doesn't have D and E,
but it does have F and G.
And so f.htm and g.html are in that develop branch.
Now, the process of rebasing master onto develop,
will result in the master branch having all of the files
that were originally in the master branch.
It's not going to lose anything,
but also gaining F and G.
And so at the conclusion of this tutorial,
we will then have,
we will now have a branch history that looks like this,
A, B and C are shared
the develop branch split from the master branch at C
and its next commits were F and G.
You can see that A, B, C, F, G,
and then we're actually going to merge master
rebase master onto develop,
which means taking masters D and E commits,
which happened after the split,
and putting them on the end of develop,
putting them after that G commit.
And so we'll have master,
we'll have masters D and E commits after F and G.
So when the rebase is finished,
we'll have this type of a commit history.
And furthermore, the master branch
will have all seven files in it.
However, we're not playing around with the develop branch.
So we're rebasing onto develop,
but we're not actually changing develop.
And so the develop branch isn't gonna change at all.
Before this whole thing starts,
the develop branch goes A B C F G,
A B C F G.
Afterwards, it doesn't change.
So it keeps all the same files,
but all of the files from each of the branches
are put into master.
I would like you to follow along
on this tutorial on your own,
if you'd like to,
you can just fork my repository
@gitlab.com/cameronmcnz/simple-rebase-and-merge-example.
Just go to my repository and you'll find it there.
It's also on my github account as well.
So from either place,
just fork it and then clone it to your own local workstation
and then play around with it.
As you can see,
I've got a developed branch and a master branch,
the master branch goes A, B, C, D, E
in terms of committing commits history.
F and G commits are on the develop branch.
And each of these commits,
I just create a file called a.html, b.html
so that when we're at the tip of master,
if I look at master and take a look at the files in it,
the tip of master has A, B, C, D E .html.
And if I take a look at the tip of development,
we can see that this particular branch has A B C
because they branched off at the third commit.
And then, the develop branch also has f and g .html.
So I'd like to merge these branches together.
I've cloned my fork onto my local machine.
So I'll move into this directory.
And you can see right now I've got
one, two, three, four, five files here in the master branch.
And we know that's the master branch,
because I can go get status.
You can see I am on the master branch.
And the operation I wanna perform
is the rebasing of the master branch
onto the develop branch.
And if I just do a get checkout.
I've developed,
and do an ls,
we can see that developed does not have D and E files,
but it does have F and G files,
which are missing in master.
And I want master to get these two files
through a rebase.
And so the command to do that is simply git rebase,
the name of the branch that you want
the branch of interest to point to,
so that's the develop branch.
That's the branch that we're going to rebase onto.
And then which brace or branch are you rebasing?
We'll we are rebasing master.
So I click enter.
It does a rewind and then a fast forward,
and you can see the result is a couple of different branches
get pushed and rewritten on top of the develop branch.
Now, what branch am I in now?
I do get status.
I can see that I'm in the master branch.
Now before the master branch had five files in it,
and it did not have the F and G files.
We are gonna do an ls command right now.
And you notice that we now have seven files,
including the F and G command.
So we've actually successfully done this rebase.
If I take a look at the log,
we can actually see that the whole history
has been rewritten.
Previously, if I looked at this commit history
before doing the rebase we would have seen,
we would have seen a branch going off at commit number C,
we would have seen the fact that,
well, we no longer have, we would have seen the fact that
at C develop added two new commits.
So develop did D and E.
And we would have seen that the, or sorry,
the master branch did D and E.
And then we would have seen that the develop branch
did F and G.
With the rebates what we've done,
is we've taken the develop branch,
which went A, B, C, F, G.
And then we've taken the D and E commits of master
and put them on top of it.
That then gives the master branch everything
that's in these commits.
Plus, the two commits that it had,
that weren't part of the develop branch.
And so, yeah, so we get seven files now.
And of course if I do a git checkout
and look at the develop branch,
you notice that the develop branch
does not have seven files in it.
So this isn't a full synchronization.
This is simply a manifestation of the fact that
master has now got all the files and develop,
but the rebase doesn't do a full synchronization
between two branches.
So we would still need to do some work to get
all of the files of master into develop.
And so that's the ins and outs
of doing a rebase onto master.
Now it's not something I recommend,
and you don't really rebase master.
You rebase other branches onto master, maybe,
but you don't rebase master onto other branches,
because if any other developers have used master,
that's gonna cause a problem.
They're gonna have a hard time syncing their changes,
and we syncing with you.
They may even have to do a fresh clone
and copy and paste changes into the new clone.
It's not a good idea.
Furthermore, even if you try and push,
so if I try and do a git push origin
to gitlab,
it's going to reject it.
$ git, Oh, sorry.
And that's it worked there because
I'm on the develop branch.
I wannna actually push masters,
So let me get checkout master.
And of course there haven't been any changes
to the develop branch.
We've just changed the history of master
in relation to the develop branch.
What I wanna do is get pushed origin of the master branch.
And you can see that this has failed.
And in this case, it said,
because the tip of your current branch
behind remote counterpart, blah, blah, blah,
fast-forward mergers rejected,
but you know, we can actually force this end.
So the whole rebasing is causing some confusion here,
but normally you can just do a force and say,
hey look, I know all about this stuff,
believe me, just take these changes.
But now I'm going to try the force,
and notice here,
it's saying, hey we failed to do this
because you are not allowed to force push code
to a protected branch.
So the force would normally have worked there, but you know,
none of your Jedi powers are gonna work,
trying to, to force a push onto the master branch,
it's protected.
So in order to do that, I'd have to go into git lab.
I'd have to have the authentication or
the authentication rights to change branch permissions,
and then I'd have to push to it.
I mean, I'm telling you there's a lot of hoops
to incorporate a merge of a rebase of master onto a branch
into your central repository.
And all of these are reasons why, you know,
maybe you should think twice about doing it.
But if you do need to do it,
this is how it's done.
And there you go, that's how you rebased master
into any branch of your choice.
Now, if you enjoyed that tutorial,
if you learn something,
why don't you head over to theserviceside.com?
I'm the editor in chief over there.
We've got lots of information on git,
git hub devops tools,
but anything that has to do
with enterprise software development,
we cover on the site as well.
And if you're interested in my antics,
you can always follow me on Twitter @Cameronmcnz and
subscribe on YouTube