为什么git要重新设置基址，而不移动任何提交？

我的设置如下所示：

- A - B - C - ... - D - E <- copy-of-master
   \ 
     F - ... - G - H <- dev
                \ 
                 I - J <- bugfix

-A-B-C-…-D-E
我想把I和J移到master的副本上，它只是上游m1/master的副本

为什么不简单地使用
git cherry pick I J

git checkout copy-of-master
git cherry-pick I J


git cherry pick…
应用主分支顶端的提交引入的更改，并使用此更改创建新的提交

您还可以指定樱桃拾取的范围

git cherry-pick <SHA-1>...<SHA-1>

git cherry pick。。。


然而，命令
gitrebase--to-copy-of-master-dev-bugfix
根本不起任何作用

预计：

git重新基址到主开发错误修复的
副本上
将在
dev
之后移动所有提交，直到
bugfix

在您的图中，
dev
（
H
）之后没有提交

假设
dev~1
（或
G
）是
bugfix
分支从
dev
派生出来的提交，那么就可以使用
--interactive
选项尝试重新基址，看看git将重新基址，这有助于解决问题我只是在猜测（请参阅我对VonC答案的评论）但我认为当您输入
git-rebase
命令时，您遗漏了最后一个
bugfix
，并在
dev
上，或者交换了
dev
和
bugfix
。这似乎不对：
git-rebase--on
意味着
主文件的副本是
，
dev
是
，而
bugfix
就是
rebase
将首先签出
bugfix
，然后使用
git rev list dev..HEAD
查找对rebase的提交，其应选择提交
I
和
J
进行复制。然后，它应该选择
E
作为
I'
的父对象的那两个，并将分支
bugfix
设置为指向
J'
。我怀疑OP的命令有误…@torek这是可能的。我只使用了
rebase--on
，通过指定我需要的确切提交（这里是
G
commit，而不是
H
或
dev
）来实现，这就是我最终要做的，但我想理解为什么rebase没有达到我的预期。在添加新提交的同时更改现有历史记录
- A - B - C - ... - D - E <- copy-of-master
   \ 
     F - ... - G - H <- dev
                \ 
                 I - J <- bugfix

git rebase --onto copy-of-master dev~1 bugfix