Git 多人协作开发实战：分支管理与冲突处理
掌握了 Git 的基础操作后，我们面临真正的挑战：多人协作。在实际项目中，如何高效地合并代码、解决冲突并维护主分支的稳定性，是衡量团队工程素养的关键。
1. 同分支下的协作模式
准备工作
虽然本地库操作已熟练，但实现多人协作需要更严谨的流程。我们的目标是让不同成员在同一个远程分支下完成修改，最终合并进 master。切记，master 分支应当保持相对稳定，日常开发建议在功能分支上进行。
假设我们在 Linux 环境下克隆了仓库充当开发者 A，再在 Windows 环境下克隆同一仓库充当开发者 B。为了模拟真实场景，我们需要确保两个用户都有权限提交代码（通常需要在平台后台添加协作者）。
首先，创建一个用于开发的分支。既可以在远程创建后拉取到本地，也可以本地创建后推送到远程。推荐在远程创建分支后再拉取，这样能确保分支基于最新的 master 状态。
git branch -a
查看本地和远程分支列表。如果看不到远端的 dev 分支，可以使用 git push 或 git pull 来同步。这里有个细节需要注意：当使用不带参数的 git push 或 git pull 时，Git 要求本地分支与远程分支建立追踪关系（upstream），否则无法确定推送或拉取的目标分支。
协作开发与冲突解决
现在模拟开发者 A 在 file.txt 中新增 "aaa"，开发者 B 新增 "bbb"。
开发者 A 切换到本地 dev 分支，修改文件并提交推送。此时远程 dev 分支已包含 "aaa"。
开发者 B 同样创建本地 dev 分支。如果直接尝试 git pull 可能会失败，因为本地分支尚未追踪远程分支。此时需手动建立连接：
git branch --set-upstream-to=origin/dev dev
建立连接后，开发者 B 尝试 push 时会遇到拒绝，因为远程分支已有 "aaa"，而本地有 "bbb"，且在同一行产生冲突。Git 无法自动判断保留哪一方，必须人工介入。
解决流程如下：
- 先执行
git pull拉取远程最新内容，触发冲突标记。 - 打开文件，根据需求保留 "aaa" 和 "bbb"，删除冲突标记。
add、commit后再次push。
合并至 Master
功能完成后，将 dev 分支合并进 master。有两种方式：
- 本地合并：在本地将 dev 合并到 master，然后 push 到远程 master。
- Pull Request (PR)：提交合并请求，经管理员审批后由平台自动合并。
推荐使用 PR 方式，便于代码审查（Code Review）。若选择本地合并，建议先在 master 分支 pull 确保最新，再进行 merge 操作，避免引入旧版本冲突。
2. 特性分支协作模式
这是更常见的现代工作流。目标是在不同分支下独立开发功能，最后统一合并。
独立开发
开发者 A 创建 feature1 分支，负责 function1；开发者 B 创建 feature2 分支，负责 function2。由于分支隔离，大家互不干扰，几乎不会发生冲突。
注意：创建本地分支前，务必先切换回 master 并执行 pull，确保基于最新的代码基线创建新分支，避免遗漏远程更新。
git checkout -b feature1 origin/master
跨分支协助
若开发者 B 请假，开发者 A 接手其 work。此时 A 需要拉取 B 的 feature2 分支。即使之前未建立追踪，git pull 也能获取到新分支信息，但后续操作建议建立连接以便管理。
