Git rebase: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
Line 11: Line 11:


==--onto==
==--onto==
 
<syntaxhighlight lang='bash'>
git rebase --onto <''newbase''>
git rebase --onto <newbase>
</syntaxhighlight>


Starting point at which to create the new commits. If the --onto option is not specified, the starting point is <font color=darkgray><''upstream''> (what does that mean?)</font>. It may be any valid commit, not just an existing branch name.
Starting point at which to create the new commits. If the --onto option is not specified, the starting point is <font color=darkgray><''upstream''> (what does that mean?)</font>. It may be any valid commit, not just an existing branch name.
Line 20: Line 21:
The option that allows specifying the ancestor commit after which all commits will be rebased. Normally, this is implicitly calculated by git with:
The option that allows specifying the ancestor commit after which all commits will be rebased. Normally, this is implicitly calculated by git with:


git merge-base --fork-point <''upstream''> <''branch''>
<syntaxhighlight lang='bash'>
git merge-base --fork-point <upstream> <branch>
</syntaxhighlight>


command. If fork-point ends up being empty as result of this command, <''upstream''> will be used as fallback.
command. If fork-point ends up being empty as result of this command, <''upstream''> will be used as fallback.
Line 27: Line 30:


Interactive rebase.
Interactive rebase.
To include a specific number of commits, going back from HEAD, use <code>HEAD~count</code>
<syntaxhighlight lang='bash'>
rebase -i HEAD~10
</syntaxhighlight>

Revision as of 02:59, 13 June 2021

Internal

Overview

git rebase reapplies commits on top of another base tip, removing the original commits. For more details on how rebasing works, and some concrete examples, see:

Git Rebasing

Options

--onto

git rebase --onto <newbase>

Starting point at which to create the new commits. If the --onto option is not specified, the starting point is <upstream> (what does that mean?). It may be any valid commit, not just an existing branch name.

--fork-point

The option that allows specifying the ancestor commit after which all commits will be rebased. Normally, this is implicitly calculated by git with:

git merge-base --fork-point <upstream> <branch>

command. If fork-point ends up being empty as result of this command, <upstream> will be used as fallback.

-i

Interactive rebase.

To include a specific number of commits, going back from HEAD, use HEAD~count

rebase -i HEAD~10