让我们--onto暂时跳过。 upstream并且branch是非常基本的，并且实际上是模仿的，checkout并且branch-第二个参数是可选的：
git branch <newbranch>
git branch <newbranch> <base>
git checkout -b <newbranch>
git checkout -b <newbranch> <base>
git rebase <upstream>
git rebase <upstream> <branch>
（题外话，在这些参数的名字rebase，“上游”和“分支”不是很描述性IMO我通常觉得他们像peachoftree。<start>而且<end>，这是我将如何使用它们： git rebase <start> <end>）
当省略第二个分支时，结果几乎与先签出该分支然后再执行该操作几乎一样，就像您没有指定该分支一样。唯一的例外是branch不会更改您当前的分支：
git checkout <base> && git branch <newbranch> && git checkout <previous_branch>
git checkout <base> && git checkout -b <newbranch>
git checkout <end> && git rebase <start>
至于了解rebase调用时的作用，我首先将其视为一种特殊的合并类型。它不是真的，但是在刚开始了解变基时会有所帮助。借用peachoftree的示例：
A--B--F--G master
\
C--D--E feature
一个git merge master结果是：
A--B--F-----G master
\ \
C--D--E--H feature
虽然git rebase master（在分支上feature！）导致以下结果：
A--B--F--G master
\
C'--D'--E' feature
在这两种情况下，feature现在都包含来自master和的代码feature。如果您未打开feature，第二个参数可以用作快捷方式切换到它： git rebase master feature将执行与上述相同的操作。
现在，特别--onto。要记住的重要部分是，<start>如果未指定，则默认为。因此，在上面，如果我--onto特别指定，将导致相同的结果：
git rebase --onto master master
git rebase --onto master master feature
（我不会--onto不加说明<end>就使用，因为这样更容易进行心理分析，甚至认为这两个如果已经启用就相同feature）。
要查看为什么--onto有用，这是一个不同的示例。假设我打开feature并发现了一个错误，然后我开始修复该错误-但它是分支出来的，feature而不是master由于错误而引起的：
A--B--F--G master
\
C--D--E feature
\
H--I bugfix
我想要的是“移动”这些提交，bugfix以使它们不再依赖于feature。实际上，此答案中上面显示的任何类型的合并或变基都会将三个feature提交与两个bugfix提交一起使用。
例如，git rebase master bugfix是错误的。范围<start>到<end>恰好包括所有从提交feature，这是对的顶部重播master：
A--B--F--G master
\ \
\ C'--D'--E'--H'--I' bugfix
\
C--D--E feature
我们真正想要的是从feature到bugfix重播的提交范围master。这就是--onto它的用途-指定与“开始”分支不同的“重播”目标：
git rebase --onto master feature bugfix
A--B--F--G master
\ \
\ H'--I' bugfix
\
C--D--E feature