When you perform a rebase, git asks for manual intervention if it can't resolve differences between your current branch and the new base branch.
If you resolve conflicts and type git rebase --continue
, git treats the resolved code as the 'new code' for that commit.
But what happens when you hit git rebase --skip
? It can't leave the code as it is—there are conflicts—so it must be doing something more than just 'skipping'.
From a content perspective, rebasing is changing the base of your branch from one commit to another making it appear as if you'd created your branch from a different commit. Internally, Git accomplishes this by creating new commits and applying them to the specified base.
Rebasing is not going to magically remove all merge conflicts. In fact, you may encounter conflicts while rebasing. Sometimes, you will have to repeatedly resolve the same conflict while rebasing. However, merge conflicts happen because multiple changes happen to the same chunk of code simultaneously.
To interrupt the rebase (just like an " edit " command would do, but without cherry-picking any commit first), use the " break " command.
If there is a conflict, git rebase --skip
simply skips the entire commit. The changes from that commit will not be in the history after the rebase finishes successfully. Let's look at an example
A-B-C <- master
\
D-E <- foo
Now say D causes a conflict after
git checkout foo
git rebase master
Then git rebase --skip
results in
A-B-C <- master
\
E' <- foo
where E' contains the same textual changes as E.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With