我是否可以在过去提交时合并来自未来的分支，而不合并它们之间的共享提交，或者不进行樱桃选择？

Question

说我有标签，v1.5。进行了更多的提交，并在标记fix之前创建了另一个分支v1.5。

现在fix中的修复已经完成，需要将其应用到由标记提交在1.5上表示的代码的发布版本。

如果不使用git-cherry-pick**，在历史上的给定点合并来自** fix 的大量提交，是可能的吗？

o  ... (history)
|
o  tag v1.5
|
o (can not have in v1.5)
|
o (can not have in v1.5)
|
o (can not have in v1.5)
|\
| \ (`fix` branch)
|  \
|   o (needed at v1.5)
o   | -(can not have in v1.5)
|   o (needed at v1.5)
|   |
|   o (needed at v1.5)
o   | -(can not have in v1.5)
    o (needed at v1.5)

Answer 1

是的，这是有可能的重新基地，而不是樱桃挑选。不管使用哪种方法，最终结果都应该是相同的。

首先，为修复分支创建一个新名称，这样原来的修复分支将保持不变。

git branch fixv1.5 fix

然后将v1.5 1.5重新固定在V1.5上

git rebase --onto v1.5 <upstream> fixv1.5

其中，<upstream>应该是fix分支所基于的提交的SHA，即在下图中标记为P的提交。

现在，您应该有这样的历史记录：

o  ... (history)
|
o  tag v1.5
| \
|  \   A'  B'  C'  D'
|   ---o---o---o---o  fixv1.5
|
o (can not have in v1.5)
|
o (can not have in v1.5)
|
o (can not have in v1.5) P
|\
| \ (`fix` branch)
|  \
|   o (needed at v1.5) A
o   | -(can not have in v1.5)
|   o (needed at v1.5) B
|   |
|   o (needed at v1.5) C
o   | -(can not have in v1.5)
    o (needed at v1.5) D

为了完整起见，樱桃采摘的等效用途将是

git checkout -b fixv1.5 v1.5
git cherry-pick <upstream>..fix