---

在项目开发中，引入新成员是一件令人兴奋的事！但随着团队人数增加，如果缺乏有效的协作规范，“代码冲突”、“分支混乱”甚至“误删核心代码”等噩梦就会接踵而至。

本文将手把手教你如何为 GitHub 团队协作制定规则，并通过一套标准的 Git 工作流（GitHub Flow），让小团队的开发变得优雅且高效。

🚨 核心铁律：永远不要直接 Push 到主干分支

在团队协作中，主干分支（通常是 main、master 或项目集成分支如 digital-cyclist）是整个项目的“神圣领地”。它必须时刻保持可用、无 Bug 的状态。

唯一的准则：
所有的代码更改都必须在独立的“特性分支”中进行，并通过提交 Pull Request (PR)，经过代码审查（Code Review）后，再由项目负责人合并（Merge）到主分支。

🌿 第一步：统一分支命名规范

无规矩不成方圆，整洁的代码库从统一的分支命名开始。推荐使用带有斜杠 / 的前缀命名法，这样主流的 Git 工具会自动将它们像文件夹一样进行归类。

• 新功能开发： feature/<功能名称>
  • 示例：feature/trainer-integration
• 非开发类任务（实验、数据采集等）： experiment/<任务名称>
  • 示例：experiment/sensor-data-run1
• 修复 Bug： bugfix/<问题描述>
  • 示例：bugfix/login-crash

🛠️ 第二步：每日标准 Git 工作流 (Cheat Sheet)

团队成员每天的开发工作，应该严格按照以下 7 个步骤闭环进行：

1. 同步最新代码

在开始任何新工作前，确保你的本地主干分支是最新的。

git checkout digital-cyclist
git pull origin digital-cyclist

2. 创建独立工作分支

基于最新的主干代码，切出一个属于你自己的分支。

git checkout -b feature/your-feature-name

3. 本地开发与充分测试

编写代码，运行你的实验。非常重要的一点： 在提交代码前，必须在本地充分测试，确保你的代码不会引发崩溃。

4. 提交你的更改 (Commit)

将测试通过的代码添加到暂存区，并写下清晰的提交信息。

git add .
git commit -m "feat: 新增了训练器集成功能"

5. 推送分支到 GitHub

将你的本地分支推送到云端仓库（首次推送需要加 -u 绑定上游分支）。

git push -u origin feature/your-feature-name

6. 发起 Pull Request (PR)

1. 登录 GitHub 网页端，进入仓库。
2. GitHub 通常会自动提示你刚才推送的新分支，点击 “Compare & pull request”。
3. 确保目标分支（Base）是主干分支，比较分支（Compare）是你的特性分支。
4. 填写改动说明，点击 Create pull request。
5. 等待项目负责人 Review。如果代码有问题，负责人会留下评论，你可以在本地继续修改并 push，PR 会自动更新。

7. 合并与清理

一旦 PR 被负责人批准并合并，你的历史使命就完成了。清理本地分支，准备迎接下一个任务：

git checkout digital-cyclist
git pull origin digital-cyclist
git branch -d feature/your-feature-name

🔒 第三步：如何从管理层面强制执行规则？

有了规范，我们该如何约束大家遵守呢？

方案 A：系统硬性约束（适用于付费私有库或公开库）

如果你使用的是 GitHub Pro/Team 企业版，或者是开源的 Public 仓库，你可以使用 Branch Protection Rules（分支保护规则）。

• 进入 Settings -> Branches -> Add branch protection rule。
• 输入你的主分支名称，勾选 Require a pull request before merging（合并前需要 PR）。
• 这样，GitHub 会在物理层面拦截任何试图直接 git push 到主分支的行为。

方案 B：君子协议（适用于免费版的私有仓库）

如果你使用的是免费版的个人账号，且仓库是 Private（私有的），GitHub 是不支持设置分支保护的。这时候我们需要依赖团队共识：

• 在项目根目录新建一个 CONTRIBUTING.md 文件。
• 将上述的命名规范、工作流以及代码保密协议白纸黑字地写下来。
• 要求每位新成员在加入前仔细阅读。哪怕有人不小心犯错，Git 强大的历史记录也能让你轻松回滚（Revert）到安全状态。

---

结语：
好的 Git 工作流虽然在前期需要一定的适应时间，但它能为你省去后期无数个熬夜排查代码冲突的夜晚。祝大家的团队合作顺利！

---