如何妥善管理互相依赖的两个Git特性分支？

1. 提取公共代码到独立分支（最优解） #

把两个分支互相依赖的对象单独提取到新分支（比如common-feature），后续操作如下：

• 让foo和bar都基于这个公共分支开发，或者将公共分支的提交分别合并/cherry-pick到两个特性分支
• 若新增公共依赖，直接在common-feature中开发，再同步到foo和bar
  这种方式能彻底切断双向依赖，同时保留两个特性分支的独立性，后续合并到main时，先合并公共分支，再分别合并特性分支即可。

2. 临时合并依赖分支（适合单人开发场景） #

如果不想抽离公共分支，可采用临时合并的方式：

• 当bar需要foo的对象时，执行git checkout bar && git merge foo，保留普通合并记录（不要用squash）
• 当foo需要bar的对象时，执行git checkout foo && git merge bar
  这种方式不会改写分支历史，避免变基带来的远程同步问题。后续向main合并时，若需要整理提交，可在单人分支上用git rebase -i调整后再推送。

3. 选择性Cherry-Pick依赖提交（精准控制依赖） #

如果仅需要对方分支中的特定提交（而非整个分支内容），可以用cherry-pick：

• 找到foo中实现目标对象的提交哈希（比如abc123），切换到bar执行git cherry-pick abc123
• 同理，找到bar中需要的提交哈希，切换到foo执行git cherry-pick def456
  这种方式只会引入必要的依赖提交，不会带入对方分支的无关修改，适合依赖点较少的场景。但要注意，若后续依赖的提交有更新，需要重复cherry-pick或处理冲突。

关于变基的补充说明 #

你之前遇到的变基后远程不同步问题，本质是变基改写了本地分支的历史，导致本地与远程分支的提交链不一致。如果这两个分支只有你自己使用，没有其他协作者推送修改，变基后可以用git push --force-with-lease强制推送（比--force更安全，避免覆盖他人未同步的修改）；但如果是多人协作的分支，变基确实不推荐，会给其他协作者带来冲突麻烦。

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