如何解决开发分支依赖问题（不合并至master分支场景）

这情况我在日常开发里碰过好多次，完全懂你不想把未完成的A合并到主分支，但新分支B又离不开A功能的痛点。这里给你几个实用的解决方案，根据你的场景选就行：

方案1：直接把A合并到B（最直观） #

这是最简单直接的方式，能让B一次性获取A的所有代码，而且完全不会影响master分支。操作步骤：

• 切换到分支B：git checkout B
• 合并分支A到B：git merge A

如果之后A分支有新的更新，你可以重复上面的操作，把A的最新代码再合并到B里。唯一需要注意的是，如果A还在迭代，合并时可能会出现冲突，解决冲突后提交即可。

方案2：将B重新基于A（更干净的提交历史） #

如果你偏好线性、干净的提交历史，用rebase会更合适。这个操作会把B的所有提交移动到A的最新提交之后，让分支历史看起来像是B直接从A开始开发的一样。操作步骤：

• 切换到分支B：git checkout B
• 执行变基：git rebase A

⚠️ 注意：如果分支B已经推送到远程仓库并且有其他同事在协作开发，不要用这个方法，因为变基会改写提交历史，导致队友的本地分支和远程分支不一致。只在B是你本地独有的分支时使用。

方案3：Cherry-pick A中需要的特定提交（按需选择） #

如果A分支比较大，而B只需要其中某几个提交的功能，没必要合并整个A，只挑选需要的提交即可。操作步骤：

• 先查看A分支的提交记录，找到需要的提交哈希：git log A
• 切换到分支B：git checkout B
• 挑选指定提交到B：git cherry-pick <提交哈希值>

你可以多次执行cherry-pick来挑选多个提交，这样B只会包含你需要的那部分代码，避免引入A中无关的改动。

后续注意事项 #

等之后A分支完成开发合并到master后，你可以把B分支重新基于master（git rebase master），这样B的历史就会对齐到最新的主分支，避免后续合并master时出现重复的提交内容。

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