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.
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.