从零开始建立团队 Git 工作流：让每一次“代码删除”都成为进化的足迹

在很多初创团队或转型中的研发小组中，Git 往往被当成了“高级云盘”。大家对着 master 分支横冲直撞，冲突了就强行覆盖，想找回一周前删掉的逻辑逻辑却发现 commit message 全是“fix”、“update”。

“删代码”不可怕，可怕的是不知道谁删的、为什么删、以及如何安全地找回来。

要建立一个让代码变更（尤其是删除和重构）有迹可循的工作流，我们需要从分支模型、提交规范和评审机制三个维度进行闭环设计。

一、 选择适合的分支模型：拒绝“大杂烩”

没有标准的分支管理，就没有追溯的基础。对于绝大多数互联网研发团队，我建议采用 GitHub Flow 的变体，兼顾效率与安全。

1. Main/Master 分支：受保护分支，永远是可部署的状态。严禁直接 Push。
2. Feature 分支：每一个新功能或优化对应一个分支，命名规范：feature/issue-id-description。
3. Hotfix 分支：紧急修复线上 Bug，命名规范：hotfix/date-description。

关键点： 所有的代码删除动作，必须发生在 Feature 分支上，并通过 Pull Request (PR) 合并。这样，删除动作就有了“上下文”。

二、 语义化提交（Conventional Commits）：给代码写“说明书”

如果你想让“删代码”变得清晰，必须强推语义化提交。一个好的 Commit 应该告诉后来者：这行代码为什么不在了？

推荐采用以下格式：
<type>(<scope>): <subject>

• feat: 新功能。
• fix: 修补 Bug。
• refactor: 重构（既不是新增功能，也不是修改 Bug 的代码变动，代码删除的高发区）。
• style: 格式化（不影响代码运行的变动）。
• chore: 构建过程或辅助工具的变动。

实战案例：
当你要删除一段过时的支付逻辑时，不应只写 delete logic，而应是：
refactor(payment): 移除已废弃的旧版支付宝 SDK 调用，改用官方聚合接口

这样，即便代码被删了，半年后的新人通过 git log --grep="refactor" 也能瞬间明白删除的背景。

三、 PR 与 Code Review：最后的防线

在合并到 main 之前，PR 是唯一能够强制执行“审计”的关口。针对“删代码”，评审者应关注：

1. 副作用评估：删除这段代码，依赖它的模块报错了吗？单元测试通过了吗？
2. 清理彻底性：配置项、无用的 import、国际化文案是否一并清理了？
3. Traceability：PR 的描述中是否关联了 Jira 或飞书文档的任务 ID？

四、 让“删代码”可追溯的进阶技巧

1. 善用 git bisect

当你发现某个功能莫名其妙消失了，却不知道是哪次提交导致的时候，git bisect（二分查找）是神器。它能帮你快速定位到那次“罪恶”的删除操作。

2. 永远不要使用 git push -f

在公共分支执行强制推送是团队协作的自杀行为。如果必须撤回，请使用 git revert。

• git reset：抹除历史，让删除变得无影无踪（危险）。
• git revert：通过一次新的提交来抵消之前的变更，历史清晰，有据可查（推荐）。

3. 自动化 Lint 约束

在本地通过 husky 配置 pre-commit 钩子，强制校验 Commit Message 格式。如果格式不对，根本提交不了。

// package.json 示例
"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
}

五、 总结

建立 Git 工作流不是为了增加开发负担，而是为了给代码库建立一套“生物化石系统”。

一个成熟的团队，应该做到：每一行被删掉的代码，都能在 Git 历史上找到它谢幕的原因。 这不仅是技术素养，更是对团队协作最基本的尊重。

你所在的团队目前在使用哪种 Git 工作流？在重构代码时遇到过哪些坑？欢迎在评论区交流。