👥 场景引入
小白：“我朋友也想一起完善知识星球，但两个人同时改代码，会不会互相覆盖？” 爱好者：“不会，只要用好 Git 的分支和协作功能，你们可以像乐队一样，各司其职，和谐演奏！” 真实痛点：
- 两人同时改一个文件，保存时互相覆盖
- 不知道对方在做什么，功能重复开发
- 代码风格混乱，像是两个人写的
- 出问题找不到负责人
Git 协作就像交响乐：有指挥、有乐谱、有各自声部，最后合成美妙乐章。
🎼 核心概念（比喻版）
团队协作的三种模式
- 独奏模式：一个人完成所有（你之前的状态）
- 二重奏：两个人，明确分工（你现在要进入的）
- 交响乐：多人团队，需要更精细的流程（未来可能遇到）
乐队比喻
角色 对应开发 职责 指挥 项目负责人 制定计划、分配任务、审查合并 乐谱 Git 分支策略 规定谁在哪个分支上做什么 声部 功能模块 前端、后端、文档等分工 排练 Code Review 互相检查，确保和谐 演出 发布上线 所有部分完美结合
🚀 手把手教学：添加你的第一位协作者
步骤1：邀请朋友加入仓库
- 进入仓库 → 点击“管理” → 左侧“仓库成员管理”
- 点击“添加仓库成员”
- 输入朋友的 Gitee 用户名或注册邮箱
- 设置权限：
权限级别 可做的事情 适合角色 报告者 提 Issue、评论 测试、提需求 观察者 报告者 + 查看代码 产品、设计 开发者 观察者 + 创建分支、提交代码 普通开发者 管理员 开发者 + 管理仓库设置 项目负责人
建议：先给“开发者”权限，足够协作又不会误操作关键设置。
步骤2：协作者接受邀请
你的朋友会收到邮件通知，或者在 Gitee 的“消息”中看到邀请，接受后就能看到仓库了。
步骤3：制定简单的协作规则
在 Wiki 中创建 "collaboration-guide.md"：
👥 协作指南
分支命名
- 功能分支：
feat/用户名/功能描述，如feat/alice/navbar - 修复分支：
fix/用户名/问题描述，如fix/bob/typo
工作流程
- 从
main切出新分支 - 开发完成 → 创建 PR → 至少一人审查
- 审查通过 → 合并 → 删除分支
沟通方式
- 小修改：PR 评论
- 大决策：Issue 讨论
- 紧急问题：即时通讯
🎯 实战：两人协作开发“评论功能”
场景设定
你想在知识星球里添加文章评论功能：
- 你：负责前端界面（HTML/CSS）
- 朋友：负责 JavaScript 交互逻辑
步骤1：创建 Issue 并分配
创建 Issue #8：
标题：✨ 添加文章评论功能 描述：用户可以在文章下方发表评论 指派给：你自己 标签：enhancement, collaboration
然后在评论中 @朋友：
@朋友用户名 你来负责 JS 交互部分吧，我写前端界面。
步骤2：分工开发
你的操作：
从main创建你的分支
git switch -c feat/yourname/comment-ui
开发界面...
git add . && git commit -m "feat: 添加评论框UI" git push -u origin feat/yourname/comment-ui
朋友的操作：
先拉取最新代码
git pull origin main
创建他的分支
git switch -c feat/friendname/comment-js
开发JS逻辑...
git add . && git commit -m "feat: 添加评论提交逻辑" git push -u origin feat/friendname/comment-js
关键：你们在不同的分支上，修改不同的文件，不会冲突。
步骤3：按顺序合并
- 你先合并 UI 分支：
- 创建 PR： "feat/yourname/comment-ui" → "main"
- 朋友审查后合并
- 朋友拉取最新 main： git switch main git pull origin main git switch -c feat/friendname/comment-js-v2
在最新代码基础上继续开发
- 朋友合并 JS 分支：
- 创建 PR： "feat/friendname/comment-js-v2" → "main"
- 你审查后合并
注意：如果两人修改了同一文件的同一部分，会有冲突，需要协商解决。
💡 避免冲突的黄金法则
法则1：经常同步
每天开始前
git switch main git pull origin main
在自己的分支上合并最新main
git switch feat/your-branch git merge main
解决可能的冲突
法则2：小步快跑
- 一个分支只做一个功能
- 一个 PR 不要太大（建议 200 行以内）
- 完成一点就提交一点，不要堆积
法则3：明确责任范围
在 "README" 或 "Wiki" 中记录：
模块负责人
- 前端界面：@你的用户名
- 交互逻辑：@朋友用户名
- 文档：双方共同维护
法则4：善用 ".gitignore"
创建 ".gitignore" 文件，避免提交个人配置：
忽略系统文件
.DS_Store Thumbs.db
忽略编辑器配置
.vscode/ .idea/
忽略环境变量
.env config.json
🔧 高级协作功能
保护主分支
在仓库设置 → 分支保护：
- 开启“合并请求审查”
- 设置至少 1 人审查才能合并
- 禁止直接向 main 分支推送
这样，所有代码都必须通过 PR 审查，质量更有保障。
代码所有者（CODEOWNERS）
在仓库根目录创建 ".gitee/CODEOWNERS"：
指定文件负责人
*.html @你的用户名 .js @朋友用户名 docs/ @你的用户名 @朋友用户名
当这些文件被修改时，会自动通知对应的人审查。
⚠️ 常见问题与误区
Q1：朋友改坏代码怎么办？
PR 审查就是为了防止这个。如果已经合并，可以用 "git revert" 回退：
找到错误的提交ID
git log --oneline
回退那个提交
git revert 提交ID
Q2：两个人要改同一个文件怎么办？
沟通 + 顺序：
- 在 Issue 里讨论谁先改
- 先改的人尽快合并
- 后改的人拉取最新代码再改
- 如果冲突不可避免，一起解决冲突
Q3：朋友很久没响应怎么办？
设置超时机制：
- 在协作规范中写明：“PR 创建 3 天无回应，可自行合并”
- 重要功能可以指定备选负责人
常见误区：
- 误区：所有人在 main 上直接开发后果：天天解决冲突，进度缓慢
- 误区：不写提交信息或写得很模糊后果：不知道这个提交是干嘛的，难以追溯
- 误区：不审查直接合并后果：代码质量参差不齐，bug 频出
📝 今日收获总结
✅ 掌握添加协作者：邀请、权限设置、接受
✅ 制定协作规范：分支命名、工作流程、沟通方式
✅ 实战分工开发：评论功能的 UI/JS 分工实现
✅ 学会避免冲突：经常同步、小步快跑、明确责任
✅ 了解高级功能：分支保护、CODEOWNERS
你们的协作状态：
👥 团队成员（2人） ├── 你：前端界面、文档 └── 朋友：JavaScript 逻辑
📁 活跃分支 ├── main（受保护） ├── feat/yourname/xxx └── feat/friendname/xxx
🔮 下篇预告 & 思考题
下篇预告：《代码审查：互相“找茬”的艺术》
有了协作，就要学会审查。下一篇深入 Code Review——如何优雅地给别人提意见，如何接受别人的建议，让代码在“找茬”中变好。 你将学到：
- 代码审查的礼仪：怎么说、怎么听
- 高效审查的技巧：重点看什么、怎么评
- 审查工具的使用：行内评论、批注
今日思考题：
- 如果你和朋友对某个功能的实现方案有分歧，应该在什么地方、以什么方式讨论？
- 为什么说“好的协作不是不冲突，而是会解决冲突”？
动手小任务：
- 邀请一位朋友成为你仓库的开发者（如果没有，可以用自己的另一个账号）
- 制定一份简单的协作规范，放在 Wiki 里
- 模拟一次协作：朋友创建一个分支，修改某个文件，提交 PR，你来审查合并
📖 延伸资源
- Git 协作工作流：Git Flow、GitHub Flow、Trunk-Based Development
- 开源项目协作规范：看 Vue.js、React 等项目的 CONTRIBUTING.md
- 沟通技巧：《非暴力沟通》在技术协作中的应用
一个人可以走得很快，一群人才能走得很远。 好的协作让 1+1 > 2，让个人项目变成团队作品。 下一节，我们学习如何优雅地“挑刺”和“被挑刺” 👀
