CODEWITHSUNDEEP
gitversion-controlgit-mergegit-rebase
Cratylus
Cratylus

Reputation: 54074

Is rebase and merge the same thing? Why are there 2 different procedures to do one thing?

I am new to git and I am trying to understand the rebase. For me the merge process is easier to understand since my experience is in Clearcase.
So first of all I can not understand if rebase is exactly the same as merge or not. If it is why are there 2 procedures for the same thing?
Also I am reading this part from git-branching.
It has here:
enter image description here

Then it says:

$ git rebase --onto master server client
This basically says, “Check out the client branch, figure out the patches from the common
ancestor of the client and server branches, and then replay them onto master.” It’s a bit complex; but the result, shown in Figure 3-32, is pretty cool.

So I assume this command means take all the commits after common ancestor of server and client branches excluding the common ancestor. So we end up with the next picture.

enter image description here

Then it says:

Now you can fast-forward your master branch (see Figure 3-33):
$ git checkout master
$ git merge client

enter image description here

This example seems wrong to me.
In the second picture we "move" C8 and C9 as result of the rebase. Then we merge.
But C8 comes out of C3 and C3 code is not present in the master branch.
After the rebase though the new C8 i.e. C8' is in front of master and actually has the master as previous in chain.
But how can this work? If C8 is dependent on C3 the rebase fails since C3 is not part of the branch.
E.g. if in C3 there is some function used by the client, it does not exist in main branch. So after the rebase the C8' will have a dependency in the function defined in C3 that does not exist in main. So the code would not compile.
Could anyone help explaining the rebase workflow and if what I say about this part of the tutorial in git-scm (that it is wrong) is correct?

Upvotes: 3

Views: 125

Answers (1)

dzada
dzada

Reputation: 5854

no it is not the same thing. rebase will put the rebased branch commits in line after the branch on which you rebase.

The basic merge will create a new commit result of the merge.

We could say that rebase avoids having too many parallel branches when merges are obvious. But in case the merge is complicated (working on same files etc) the merge is better. This is because when remerging, git recompute the diffs, like

a = b + diff a c= b + diff c

merge is d = a + c rebase is cbis = a + diff cbis

and diff c is probably easy to read, diff cplus might be complicated

also there is the fast forward option that tries to merge in line (like rebase) if the diff is simple, and creates a merge if not. This is probably the best for beginners

Upvotes: 1

Related Questions