你怎么能直接 commit 到我的 main 分支啊！？—— 一个抖音视频引出的 Git 协作规范指南
抖音上刷到 Antidote 的一个视频，用鸣潮角色西格利卡吐槽： “你怎么能直接 commit 到我的 main 分支啊？！”
笑完之后发现，这一连串吐槽其实把 Git 协作的最佳实践串了个遍。整理一下，既是备忘，也当科普。
🎬 先看原片台词
你怎么能直接 commit 到我的 main 分支啊？！GitHub 上不是这样！
你应该先 fork 我的仓库，然后从 develop 分支 checkout 一个新的 feature 分支，比如叫 feature/confession。
然后你把你的心意写成代码，并为它写好单元测试和集成测试，确保代码覆盖率达到 95% 以上。
接着你要跑一下 Linter，通过所有的代码风格检查。
然后你再 commit，commit message 要遵循 Conventional Commits 规范。
之后你把这个分支 push 到你自己的远程仓库，然后给我提一个 Pull Request。
在 PR 描述里，你要详细说明你的功能改动和实现思路，并且 @ 我和至少两个其他的评审。
我们会 review 你的代码，可能会留下一些评论，你需要解决所有的 thread。
等 CI/CD 流水线全部通过，并且拿到至少两个 LGTM 之后，我才会考虑把你的分支 squash and merge 到 develop 里，等待下一个版本发布。
你怎么直接上来就想 force push 到 main？！GitHub 上根本不是这样！我拒绝合并！
🔧 逐条拆解这些术语
1. Git 分支模型
| 术语 | 说明 |
|---|---|
| main | 主分支，项目的”正式发布版”，一般情况下不允许直接在上面提交。 |
| develop | 开发分支，日常集成的目标。新功能从 develop 分出来，开发完成后合并回来。 |
| feature 分支 | 功能分支，从 develop 拉出，命名如 feature/login、feature/confession。互不干扰。 |
| fork | 把别人的仓库复制到你自己的 GitHub 账户下。你在 fork 里随便改，不影响原项目。改好了再通过 PR 把改动”喂回去”。 |
| squash and merge | 把 feature 分支上的多个小 commit 压缩成一个，再合并到 develop。保持主干历史干净得像新的一样。 |
💡 为什么不能直接 push main？
想象一下：你正在写期末论文，别人二话不说直接在你文档第一页改了几个字、删了两段——你还没保存前版本，找都找不回来。
force push相当于：“别管你之前写了啥，现在这是我的版本了”。多人协作时这是大忌。
2. 代码质量工具
Linter（代码风格检查工具）
Linter 是一个自动检查代码规范的工具。它会抓出：
- 变量没用到 → ❌
- 缩进不对 → ❌
- 少了分号 → ❌
- 函数太长 → ⚠️
- 有潜在 bug 的写法 → 🚨
常见 Linter：
| 语言 | Linter |
|---|---|
| JavaScript / TypeScript | ESLint |
| Python | Pylint、Flake8、Ruff |
| CSS | Stylelint |
| Go | 自带 gofmt，且 go vet 查深层问题 |
| Rust | Clippy |
怎么用？
- 编辑器方案（推荐新手）：VS Code 装对应插件，写代码时自动红线提示，不用记命令。
- 命令行方案：
eslint 你的文件.js，跑一下就告诉你所有问题。
单元测试 & 集成测试
| 类型 | 测什么 | 举例 |
|---|---|---|
| 单元测试 | 最小代码单元（一个函数/方法） | test_add() 验证 add(1,2) == 3 |
| 集成测试 | 多个模块协同工作 | 注册→发邮件→存数据库，整条链路通不通 |
代码覆盖率 95%：意味着你 100 行代码里有 95 行都被测试跑过。比例越高，代码越”安全”——但也别钻牛角尖追求 100%。
3. 协作规范
| 术语 | 含义 |
|---|---|
| Conventional Commits | 提交信息的规范格式：类型(范围): 描述。如 feat(login): 添加短信验证码登录。类型有 feat（新功能）、fix（修 bug）、docs（文档）、refactor（重构）…… |
| Pull Request (PR) | 你想让别人把你的代码合并进去——在 GitHub 上提交一个请求，等待审核。 |
| Code Review | 其他人看你的代码，找出潜在问题、提出改进建议。 |
| Thread | 评论中的讨论串。每一个评论就是一个 thread，**全部 resolved（解决）**后才能合并。 |
| LGTM | Looks Good To Me（我看行）。Code Review 通过的标准用语。通常需要至少 2 个 LGTM 才能合并。 |
| @ 某人 | 在 PR 里 @ 指定的人来审查。相当于在群里 @ 人：“快来看这个 PR！” |
4. CI/CD（持续集成 / 持续部署）
自动化的流水线。你 push 代码后，服务器自动跑：
- Linter → 代码风格检查
- 单元测试 → 所有用例是否通过
- 构建 → 项目能不能正常编译/打包
- 部署 → 通过后自动发布到线上
一套下来，人只需要写代码、等结果。
🚫 视频里的反面典型
视频吐槽的核心行为是：
git commit -m "1111"git push --force—— 直接在别人的 main 分支上 强制覆盖推送。
评论区经典评论：
NaNw：“叽里咕噜说啥呢，git commit -m ‘1111’，git push —force”
zip8919：“这个 1111 还好，这个 force 吓哭了，我之前写的代码就是被别人 force 掉了”
磷葉：“对不起老大，我给 main 分支提交了八十个 G 的垃圾文件，不过不要担心，我已经及时 revert 了，就是拉代码的时候怎么卡卡的”
小小灰：“叽里咕噜说啥呢，公司就我一个开发，主分支就是我的工作分支”
✅ 正确的 Git 协作流程（简化版）
你发现了一个有趣的仓库 │ ▼ ① Fork（复制到你的 GitHub 账号下） │ ▼ ② git clone 你的 fork 到本地 │ ▼ ③ git checkout -b feature/xxx（创建功能分支） │ ▼ ④ 写代码 → 写测试 → 跑 Linter │ ▼ ⑤ git commit（遵循 Conventional Commits） │ ▼ ⑥ git push 到你自己的远程仓库 │ ▼ ⑦ 提 Pull Request 到原仓库 │ ▼ ⑧ Code Review → 解决 Threads → CI/CD 通过 │ ▼ ⑨ Squash and Merge → 完成 🎉🛠️ 新手常见问题
Q: Linter 需要我单独安装软件吗？
不需要单独装”Linter 软件”。
- 如果用的 VS Code：装对应语言的扩展插件就行。比如写 JavaScript 装 ESLint 插件，写 Python 装 Pylint 插件——装好之后代码里直接红线标出问题，比 Word 的拼写检查还直观。
- 如果用的 WebStorm / IntelliJ：自带 Linter 支持，开箱即用。
- 如果你想在命令行用：
npm install -g eslint（JS）、pip install pylint（Python）→ 然后eslint 文件.js。
Q: 就我一个人开发，也需要这么麻烦吗？
可以简化。但养成好习惯总是好的：
- 至少用个 main + develop + feature 分支 的结构
- commit message 写得清晰点（不用严格按规范，但别只写”1111”）
- 千万别 force push 到 main
📺 原视频信息
- 作者：Antidote
- 发布时间：2026-06-19
- 点赞：4416 | 评论：148 | 收藏：2261
- 标签：#编程 #GitHub #鸣潮 #西格利卡 #二创
- 原链接：抖音视频
最后送大家一句评论区看到的真理：
“git push —force 之前，先想想这代码是不是只有你一个人在写。”
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！
音乐
暂未播放