先前的大多数答案都是危险的错误提示！
不要这样做：
git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch
下次您运行git rebase（或git pull --rebase）时，这3个提交将被静默从newbranch！（请参阅下面的说明）
而是这样做：
git reset --keep HEAD~3
git checkout -t -b newbranch
git cherry-pick ..HEAD@{2}
- 首先，它丢弃最近的3次提交（
--keep例如--hard，但更安全，因为失败而不是丢弃未提交的更改）。
- 然后它分叉
newbranch。
- 然后，将这3个提交重选到
newbranch。由于它们不再被分支引用，因此它使用git的reflog来实现：HEAD@{2}是HEAD以前用来引用2个操作的提交，即在我们1.检出newbranch和2. git reset丢弃3个提交之前。
警告：reflog默认是启用的，但是如果您手动禁用了reflog（例如，通过使用“裸露”的git仓库），则运行后将无法取回3次提交git reset --keep HEAD~3。
不依赖引用日志的替代方法是：
# newbranch will omit the 3 most recent commits.
git checkout -b newbranch HEAD~3
git branch --set-upstream-to=oldbranch
# Cherry-picks the extra commits from oldbranch.
git cherry-pick ..oldbranch
# Discards the 3 most recent commits from oldbranch.
git branch --force oldbranch oldbranch~3
（如果您愿意，可以编写@{-1}-先前签出的分支-代替oldbranch）。
技术说明
为什么git rebase在第一个示例之后丢弃3次提交？这是因为默认情况下，git rebase不带参数--fork-point的情况下会启用该选项，该选项使用本地reflog尝试对强行推入的上游分支保持鲁棒性。
假设您在包含提交M1，M2，M3的情况下分支了Origin / master，然后自己进行了三个提交：
M1--M2--M3 <-- origin/master
\
T1--T2--T3 <-- topic
但是随后有人通过强制按原点/原版来重写历史记录以删除M2：
M1--M3' <-- origin/master
\
M2--M3--T1--T2--T3 <-- topic
使用本地reflog，git rebase可以看到您是从Origin / master分支的较早版本分支出来的，因此M2和M3提交实际上并不是您的主题分支的一部分。因此，可以合理地假设由于M2已从上游分支中删除，因此一旦主题分支重新建立基础，您就不再希望在主题分支中使用它：
M1--M3' <-- origin/master
\
T1'--T2'--T3' <-- topic (rebased)
这种行为是有道理的，并且在重新定基时通常是正确的做法。
因此以下命令失败的原因：
git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch
是因为它们使reflog处于错误状态。Git认为newbranch是在包含3个提交的修订版中分支了上游分支，然后reset --hard重写了上游的历史记录以删除提交，因此下次运行git rebase它将像从上游删除的任何其他提交一样丢弃它们。
但是在这种特殊情况下，我们希望将这3个提交视为主题分支的一部分。为此，我们需要在不包含3个提交的早期版本中分叉上游。这就是我建议的解决方案所做的，因此它们都使reflog保持正确的状态。
有关详细信息，请参阅定义--fork-point在git的底垫和混帐合并基础文档。