如何高效将基于彼此的链式Git分支合并到master分支？

我习惯把大型工作拆分为多个依赖前置分支的子功能分支，比如开发功能foo时会创建：

• /me/foo/part1
• /me/foo/part2（基于/me/foo/part1）
• /me/foo/part3（基于/me/foo/part2）
• /me/foo/part4（基于/me/foo/part3）

开发阶段，更新part1后（比如代码评审修改或合并master变更），我会把part1合并到part2，这个过程几乎没有冲突。但当part1合并到master后，尝试将part2重基于master（或发起master到part2的合并请求）时，却总是出现大量冲突——按道理part1已经合入master，代码树应该和part2的基础一致，不该有这么多冲突。请问有没有办法让这个「重定向」过程更顺畅？

1. 用交互式变基替代合并master到part2 #

当part1合入master后，不要用合并操作，而是对part2执行变基：

# 拉取最新master分支
git checkout master
git pull

# 切换到part2分支
git checkout /me/foo/part2

# 以master为基准执行交互式变基
git rebase -i master

变基时Git会把part2中基于part1的提交「重播」到master之上，由于part1的提交已在master中，Git会自动识别并跳过这些重复提交，只保留part2独有的变更，大幅减少冲突概率。

2. 日常同步保持分支历史线性 #

平时更新part1后，不要用普通合并（git merge part1）同步到part2，改用变基：

git checkout part2
git rebase part1

这样part2的提交历史会是基于part1的线性链，当part1合入master后，part2的所有提交都是part1最终版本之上的新增内容，变基到master时Git能更精准匹配已合入的提交，避免冲突。

3. 精准变基跳过已合入的前置分支提交 #

如果part2包含大量提交，可使用--onto参数指定仅将part2中part1之后的提交移植到master：

# 先找到part1最后一个提交的哈希值，比如abc123
git rebase --onto master abc123 /me/foo/part2

这会彻底跳过part1的所有提交，只处理part2独有的变更，从根源避免因提交历史混乱导致的冲突。

4. 规范处理冲突 #

若仍遇到冲突，使用可视化合并工具（如VS Code内置工具、Beyond Compare）处理，完成每个冲突文件后执行：

git add <冲突文件名>
git rebase --continue

不要手动修改后直接提交，确保Git正确识别冲突已解决。

5. 及时同步后续分支 #

当part2成功变基并合入master后，对part3、part4重复上述变基操作，保持整个分支链的线性，后续的重定向过程也会更顺畅。

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