如何将最近（但不是最新）的提交移动到新分支答案

【问题标题】：How do I move recent (but not latest) commits to a new branch如何将最近（但不是最新）的提交移动到新分支
【发布时间】：2013-11-04 15:18:14
【问题描述】：

即我该怎么走

大师：A-B-C-D-E-F-G

到

大师：A-B-E-F-G \ 特点：CD

现在很明显，CD 应该在一个特性分支中，因为该更改现在被延迟了。

这与我见过的其他问题 here 和 and here 略有不同

【问题讨论】：

这是（目前）三个可行的答案。各有优势吗？我非常喜欢@larsmans 樱桃挑选解决方案，因为它不需要变基
但它确实需要变基...
啊是的。它没有它。拍自己的头。那么我该尝试第一个吗？还是它们都是等价物？
既然我已经回顾了--onto 所做的事情，我不得不承认，我认为 R0MANARMY 的答案实际上只是勉强好一点，尽管我的投票数更多。唯一真正的区别是我的版本（使用-i 进行交互式rebase）需要您手动选择提交C 和D 以进行删除，而--onto 版本在一个命令行中自动执行此操作。至于被删的第三个答案，还好，但比较啰嗦。（虽然我喜欢它提到的备份想法，我以前自己也用过。）

标签： git branch git-branch revision-history

【解决方案1】：

从master的HEAD(G)开始：

git branch feature D  # Create new branch at D.
git rebase -i B       # Use interactive rebase to remove C D from master.

【讨论】：

【解决方案2】：

此答案假设您没有推送 master 或者您是唯一参与该项目的人（在这种情况下，这并不重要）。如果您推送了 master 并且其他人提取了您的更改，则您需要与他们沟通以确保他们适当地更新其存储库。

                                  # Assuming you're on master
git branch <feature> <D>          # Create a branch named <feature> at commit <D>
git rebase --onto <B> <D> master  # Transplant branch

Git rebase 文档对 rebase --onto 的作用有很好的图形解释。

如果你想完全避免rebase，你应该可以这样做

git branch <feature> <D>          # Create a branch named <feature> at commit <D>
git revert <D>                    # undo D
git revert <C>                    # undo C

这将导致这样的历史记录

A-B-C-D-E-F-G-!D-!C
      ^           ^
   feature      master

任何签出 master 的人都会看到代码，就好像提交 C 和 D 从未发生过，你只会有几个reverts 在您的历史记录中。这是从已推送的分支中支持更改的首选方式。

【讨论】：

使用revert版本 - 分支已经被推送，所以不重写历史是一个主要的+。
答案的回复部分只是对您要查找的内容的幸运猜测。您应该在问题中说明您正在寻找不涉及rebase 的答案。
直到你指出如果我推了主人的危险，我才完全理解它的重要性：到那时你已经回答了:-) 谢谢！