Why is git doing a rebase in multiple steps?-CodePudding

I had to rebase a feature branch on a develop branch.

So I just did a rebase and it had me do this rebase operation in 5 steps.

I could see these markers:

REBASE 1/5
REBASE 2/5
REBASE 3/5
REBASE 4/5

The first git rebase <branch> command gave me some conflicts. So I edited the files, added them and finally did a git rebase --continue command. But it asked me: No changes - did you forget to use 'git add'? I then had to issue the git rebase --skip command, which showed additional conflict files not shown at the first step. And I had to repeat the operation multiple times, in this case, some 5 times, to finally have a Applying: displayed showing there were no more conflicts and that the rebase had completed.

CodePudding user response：

Let's say that your local and remote branch looked like this before the rebase:

remote:  A -- B
          \
local:     C -- D -- E -- F -- G

A rebase of local against remote would result in the following branch diagram:

remote:  A -- B
               \
local:          C' -- D' -- E' -- F' -- G'

That is, the rebase starts using the new base of A -- B for your branch. It then reapplies the 5 commits C through G on top of this new base. Each "step" of the rebase, as you perceive it, involves applying one of these commits on top of the new base.

Regarding fixing the same thing multiple times, a merge conflict will be triggered if a given line or lines both have been changed in the HEAD commit of the new base and the commit being applied. If that keeps happening, the same region of code will keep getting flagged with a conflict.

An exact example would be your resolving a line of code to merge with the HEAD of the initial new base (commit B in the above diagram). With each successive applied commit, you reintroduce the old logic, which then needs to be resolved again. You may consider a rebase as being like a slow motion merge, where the changes get layered on bit by bit, like baking a cake.

CodePudding user response：

A rebase works the way that the base of a branch (the point where the branch diverts from other branches) is modified to another commit. Thats what gives the operation it's name. The operation therefore changes the commit (including new timestamp) and it therefore has a new hash. Simply speaking, it is a complete new commit that is being created.

Since all following commits are dependent on the previous commit they need to be changed aswell, otherwise your history would be completely broken. For that reason, there are multiple steps involved (one per commit).

Apart from that, a rebase offers you more options like squashing commits together, edit commit messages, or picking/skipping specific commits. Obviously you cannot do this in one step, so it is being done step by step.