Git跨分支变更引用技术问询：如何在特性分支B中引用分支A的变更且不产生重复提交或暂存变更？

你的需求在Git里完全是可行的，核心是要让分支B复用分支A的原始提交，而非创建新的提交副本——这样Git后续合并时就能通过提交ID识别出这些变更已经存在于A中，自动跳过重复操作。你提到的cherry-pick、rebase、merge其实都能实现这个目标，可能是对它们的用法或适用场景理解有偏差，下面我详细拆解可行的方案：

方案1：变基（Rebase）—— 适合个人特性分支场景 #

如果分支B是你独自维护的（没有多人协作），变基是最干净的实现方式：

1. 切换到分支B：git checkout feature/B
2. 将B的提交变基到分支A的最新状态：git rebase feature/A

这个操作会把分支B的所有提交“移动”到分支A的最新提交之后，相当于让B直接基于A的最新代码继续开发。此时分支B的历史会完整包含A的所有原始提交，没有任何重复提交。后续你把B合并回A时，Git会发现B的提交都是基于A的，只会合并B独有的变更，完全不会出现重复操作。

注意：如果分支B已经推送到远程仓库且有其他开发者协作，不推荐使用rebase（会改写公共历史），这种情况可以看方案2。

方案2：合并（Merge）—— 适合多人协作分支场景 #

如果分支B是多人协作的，不能改写历史，那就用普通的合并操作：

1. 切换到分支B：git checkout feature/B
2. 合并分支A的变更到B：git merge feature/A

这会生成一个合并提交，记录B和A的合并点。后续合并B回A时，Git会通过合并提交的信息识别出A已经包含了之前合并进来的变更，只会处理B在合并之后新增的提交，不会执行重复操作。

如果你不想保留合并提交，可能会想到git merge feature/A --squash，但这个命令会把A的变更作为暂存修改放到B中，需要手动提交——这样会生成新的提交副本，后续合并回A时反而可能出现重复，所以不推荐使用这个参数，保留正常的合并提交更安全。

方案3：临时引用分支（Git指针特性）—— 轻量化临时场景 #

如果你的需求只是在开发时临时“引用”A的变更，不需要把A的变更整合到B的历史中（比如临时测试），可以直接在分支B上基于A的提交创建临时工作区：
git checkout feature/B && git reset --hard feature/A
不过这个操作会覆盖B的当前代码，仅适合临时场景。如果要回到B的原始状态，执行git reset --hard feature/B@{1}即可。

为什么你觉得cherry-pick不行？ #

cherry-pick确实会生成新的提交副本，所以后续合并回A时会出现重复——哪怕用git cherry-pick -x标记原始提交ID，也只是方便手动处理重复，并非最优解，所以确实不推荐用cherry-pick来实现你的需求。

总结一下：个人分支优先用rebase，多人协作分支用正常merge，这两种方法都能满足你的需求，让Git在后续合并时自动识别重复变更，不会执行重复操作。

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