是否有可能将一组提交追溯到一个分支？
假设我有一个git仓库，我一直在做主，我可以追溯创build一个分支。 例如：
A – B – C – A1 – D – A2 – E
我想使它看起来像这样：
A - A1 - A2 \ \ B - C - D - E 具体的用例是当我挑选了一堆提交到一个旧版本的分支，它需要进入多个旧版本，我不想重复所有这些修订的樱桃select。
从本质上讲，它本来就是一个很好的function或主题分支，但并不是这样创build的。
当然可以。 （用Git没有什么比你不能做任何事情:)
git checkout -b new-branch hash-of-A git cherry-pick hash-of-A1 git cherry-pick hash-of-A2
这将创build一个新的分支，从提交A 。 之后再次返回到相同的提交，创build另一个分支：
git checkout -b new-branch2 hash-of-A git cherry-pick hash-of-B git cherry-pick hash-of-C git cherry-pick hash-of-D git cherry-pick hash-of-E git merge new-branch
现在你只需要合并new-branch和new-branch2 new-branch来获得你想要的结构并放弃你的旧分支。
当然，达斯汀所说的仍然存在：提交的哈希值将会改变，所以如果你还没有发布你的改变，你应该这样做。
如果你想在修订版XXX之后的所有提交发生在一个分支，我发现这比其他提议的方法更容易。
$ git branch fixes # copies master to new branch $ git reset --hard XXX # resets master to XXX
这在git的帮助页面中描述，在“撤消提交，使其成为主题分支”下进行reset 。
你不能透明地做到这一点，因为哈希将不得不改变，但你基本上只需要分支HEAD和rebase -i两个分支放弃相应的变化。
忘记所有的樱桃采摘。 只需要重新分配两次就省略了变更，每次都创build一个新的分支，然后合并2个分支。
你想要做的是实际上重写历史。 提交的标识符将会改变，并且在某些情况下，提交提供的变更集会改变。 所以如果有人有机会在旧版本的分支上进行工作，那么最好不要这样做。 但如果你没有发布这个分支，感觉自由。
让我们假设我们想要改变的分支被命名为“master”，并且我们想要开始新分支的点被命名为“A”（在给出的例子中，可以使用的名字是'master〜6'）。
首先，让我们从提交'A'创build新的分支，让我们将其命名为'修复'
$ git checkout -b fixes A
这也会使分支“修复”成为现实。 因为只有一些我们想要挑选的提交，我们可以在分支的“修复”中挑选它们：
$ git cherry-pick A1 $ git cherry-pick A2
然后我们要从分支“主”中删除提交'A1'和'A2'。 因为我们想删除的提交只有几个，可能还有更多，我们可以使用'git rebase -interactive'来实现：
$ git rebase -i fixes master
在提交'A'（这是常见的提交，即分支“主”和分支“修复”的合并基础）之后，编辑器将会触发“主”中的所有提交。 该列表将如下所示：
pick deadbee B pick fa1afe1 C pick a98d4ba A1 ...
删除提交'A1'和'A2'的行，保存更改，closures编辑器（或者发送更改为内敛的rebase），git会重新应用除提交的所有提交。
然后你可以敲定
$ git merge fixes
（git-rebase让我们改写了分支'master'）。
