如何让开发者专注特定分支并实现无冲突合并？

1. 定期同步上游分支到featureX #

不要等到两周后才合并，每周至少1-2次将最新的development分支合并到featureX：

git checkout featureX
git pull origin development
git merge development
# 解决冲突后提交并推送到远程
git add .
git commit -m "Sync development to featureX, resolve conflicts"
git push origin featureX

提前同步能把大冲突拆解成小冲突，每次处理成本更低，也能及时发现上游分支的变更对当前feature的影响。

2. 子分支合并到featureX的前置规范 #

要求每个开发者在合并自己的子分支（如featureX-John）到featureX前，先同步featureX到自己的子分支：

git checkout featureX-John
git pull origin featureX
git merge featureX
# 解决自己分支内的冲突后，再提交合并请求到featureX

这样所有子分支的冲突都在个人分支层面解决，featureX始终保持相对干净，不会积累大量待处理的冲突。同时鼓励小粒度合并：完成一个独立的小功能模块就合并到featureX，而非等整个大功能开发完成再合并。

3. 代码层面规避冲突风险 #

• 明确功能模块划分：让不同开发者负责的功能尽量减少交叉修改，比如A负责后端接口、B负责前端页面，避免同时修改同一文件的同一代码块。
• 公共文件约定：对于配置文件、基础工具类这类多人可能修改的文件，提前约定修改规则，比如用注释标记各自负责的区块，或者修改前在团队内同步，减少无意义的冲突。

4. 可选：用Rebase优化提交历史（谨慎使用） #

如果团队偏好线性的提交历史，可以在同步development到featureX时使用rebase替代merge：

git checkout featureX
git pull origin development
git rebase development
# 分提交逐步解决冲突，完成后推送（注意：如果featureX已被多人协作，需要加--force-with-lease）
git push origin featureX --force-with-lease

Rebase会把featureX的提交重新应用到最新的development之上，历史更整洁，但会修改提交历史，仅适合featureX未被多人共享或团队统一认可的场景。

5. 合并前预检查 #

正式合并featureX到development前，先在本地做预合并验证：

# 创建临时分支
git checkout -b temp-merge-featureX-development
# 合并最新的development和featureX
git merge origin/development
git merge origin/featureX
# 解决所有冲突后，确认功能正常，再执行正式的合并操作

这样可以避免在远程合并请求（PR）中暴露大量冲突，提升团队协作效率。

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