TypeScript 的 Git 工作流：如何在类型化代码中保持清醒

TypeScript 的 Git 工作流：如何不再害怕合并冲突

如果你曾经尝试合并两个分支，其中一个修改了 User 接口，而另一个在同一个模块中添加了新类型，你就会知道什么是开发者的存在主义危机。TypeScript 为我们提供了强大的类型系统，但如果没有正确的 Git 工作流，这种强大就会变成头疼的问题。

在本文中，我们将分析TypeScript 项目的最佳 Git 工作流——从分支设置到每次提交时的自动类型检查。没有废话，只有实战中真正有效的内容。

为什么 TypeScript 需要特殊的 Git 方法？

TypeScript 不仅仅是“带类型的 JavaScript”。它是一种语言，每次更改都可能通过 interface、type 和泛型影响数十个文件。一个基本类型的错误修改就可能导致整个项目无法编译。

因此，标准的 TypeScript Git 工作流 必须包括：

\n
• 提交前必须进行类型检查
\n
• 代码检查器，防止提交未格式化的代码
\n
• 清晰的分支策略，避免合并冲突破坏类型
\n
• 在服务器上重新检查一切的 CI/CD
\n

让我们逐一分析每个要点。

1. 选择分支策略：Git Flow 还是基于主干？

对于 TypeScript 项目，我推荐基于主干的开发，配合短期分支。为什么？因为 TypeScript 代码本质上是“原始”代码，需要快速检查和部署。长期分支会导致类型“偏离”。

基本分支结构

main        — 稳定版本，始终可部署\ndevelop     — 主要开发分支\nfeature/*   — 新功能（存活1-2天）\nfix/*       — 错误修复\nrelease/*   — 发布准备（可选）\n

TypeScript 项目示例：

git checkout -b feature/add-user-validation\n# 工作...\ngit commit -m "feat: add email validation for User type"\ngit push origin feature/add-user-validation\n# 创建 PR → 合并到 develop\n

重要提示：如果项目中有共享类型，切勿对 main 进行变基。使用合并——它保留历史记录且不会破坏依赖关系。

2. Git 钩子：防止犯错（也防止自己犯错）

最常见的场景：你忘记运行 tsc，提交了，推送了，然后 CI 失败了。为了避免这种情况，我们设置预提交钩子。

安装 Husky + lint-staged

Husky 是用于管理 Git 钩子的工具。lint-staged 仅对更改的文件运行命令。

npm install --save-dev husky lint-staged\nnpx husky init\n

创建文件 .husky/pre-commit：

#!/usr/bin/env sh\n. "$(dirname -- "$0")/_/husky.sh"\n\nnpx lint-staged\n

在 package.json 中添加：

{\n  "lint-staged": {\n    "*.ts": [\n      "eslint --fix",\n      "prettier --write",\n      "tsc --noEmit"\n    ]\n  }\n}\n

现在每次提交前：

\n
1. 运行 ESLint 并自动修复
\n
2. 通过 Prettier 格式化代码
\n
3. 检查 TypeScript 编译 (tsc --noEmit)
\n

如果任何一步失败——提交将不会通过。虽然残酷，但很有效。

3. 正确的提交信息：约定式提交

TypeScript 项目受益于约定式提交，因为：

\n
• 自动生成变更日志
\n
• 容易理解哪些更改破坏了类型
\n
• 可以仅针对特定提交触发 CI
\n

示例：

feat: add UserRole enum and validation\nfix: c