长期运行的cherry-pick分支如何避免向master合并时重复引入已迁移提交？

你执行git cherry -v master featureXY时，已完成cherry-pick的提交依然会被列出，属于Git的正常表现：git cherry是通过比对两个分支提交的补丁ID（patch-id）识别重复改动的，你在cherry-pick过程中做了手动修改，补丁内容和featureXY上的原提交不一致，自然无法匹配到已存在的改动。

你想要的“不合并某一指定提交之前的所有提交”的操作可以直接实现，完全不需要担心重复带入之前cherry-pick过的内容，具体分两种可落地的方案：

• 方案一：按已知的最后一个已同步提交做选择性合并
  如果你能明确找到featureXY上最后一个已经被cherry-pick到master的提交SHA（比如记为abc123），不需要全量合并整个featureXY分支，直接执行以下命令就能只合并这个SHA之后的新提交：
  git merge featureXY...abc123
  这个命令的逻辑是，仅取featureXY分支上从abc123到当前分支头部的所有改动合并到master，完全不会把abc123及其之前的提交纳入合并范围，从根源上避免重复带入已经cherry-pick过的旧提交。
• 方案二：全量合并时跳过已同步的旧提交
  如果你没法明确标记出最后一个已同步的提交SHA，可以先执行不带自动提交的全量合并：
  git merge --no-commit --no-ff featureXY
  合并过程中Git会尝试把featureXY的所有改动拉到工作区，你只需要手动检查改动内容，把那些已经在master上存在的、通过之前cherry-pick带过来的改动还原成master的现有状态，再完成提交即可。遇到这类旧改动和master内容的冲突时，直接选择保留master的版本跳过即可，不需要重新调整。

几个注意点：

• 第一次完成上述合并后，后续两个分支的同步就可以直接用常规的git merge命令执行。因为这次合并会在两个分支之间建立明确的共同提交标记，Git不会再把之前已经同步过的提交算成差异项。
• 不要通过交互式变基的方式从featureXY上删掉已经同步过的旧提交。featureXY是长期并行开发的分支，一旦改写历史，所有协作这个分支的人都会碰到历史不匹配的问题，维护成本远高于选择性合并的方案。
• 如果长期并行开发两个分支，尽量减少逐提交cherry-pick的操作，优先使用正常merge同步改动。cherry-pick生成的提交和原分支的提交没有直接关联，哪怕内容完全一致，Git也没法自动识别重复，后续同步的维护成本会高很多。

内容的提问来源于stack exchange，提问作者jnemecz