应采用 Conventional Commits 规范：<type>(<scope>): <subject>，如 feat(user): add email validation，首行≤72字符、不加句号，空行后写正文说明动机与影响，禁用模糊表述。
Git 提交历史混乱，根本原因不是没写 git commit，而是每次提交缺乏一致的意图表达和结构约束——不规范的提交信息、随意的分支命名、跳过的代码审查，都会让 git log 变成考古现场。
怎么写一条合法又可读的提交信息？
Git 本身不限制格式，但团队协作中，git log --oneline 能否一眼看出“改了什么、为什么改、影响范围”，全靠提交信息是否遵循约定。推荐采用 Angular 团队演进出来的 conventional commits 约束（非强制，但极有效）：
-
feat:新功能（如：feat: add user email validation） -
fix:修复 bug（如：fix: prevent null pointer in auth middleware） -
chore:构建/CI/工具类变更（如：chore: update eslint config to v8.5） -
docs:文档修改（如：docs: clarify api rate limit section） - 第一行不超过 72 字符，句末不加句号
- 空一行后写正文，说明动机、对比旧行为、是否含破坏性变更（BREAKING CHANGE）
别用 git commit -m "update stuff" 或 git commit -m "fix bug" ——这些信息在三个月后对你自己都毫无意义。
为什么 git rebase -i 比 git merge 更适合日常开发？
不是为了“看起来干净”，而是为了保持每个提交都具备独立可测试性与语义完整性。当你在 feature 分支上连续提交了 12 次，其中 5 次是 fix typo、3 次是 try different approach，直接 git merge 进主干，等于把调试痕迹也永久写入历史。
用 git rebase -i main（或 git rebase -i HEAD~5）可以：
- 把零碎提交
squash成逻辑单元（比如把 4 次 API 调试合并为feat: implement /v2/search endpoint） - 用
reword修正错误的提交信息，不用等 PR 合并后再后悔 - 用
drop删除误提交的调试代码（如临时console.log、硬编码 token） - 注意：仅对尚未推送到远程的本地提交做交互式变基；已推送的提交变基后需
git push --force-with-lease，且要确保没人基于它继续开发
如何防止“一提交就破 CI”？本地预检比等 GitHub Actions 报错更省时间
很多团队把 lint、test、type-check 全堆在 CI 上，结果每次提交都要等 3–5 分钟才被告知 eslint 失败——这不是 CI 的问题，是你漏掉了本地守门人。
在 package.json 中配好脚本后，用 husky + lint-staged 建立 pre-commit 钩子：
npm install husky lint-staged --save-dev npx husky install npx husky add .husky/pre-commit "npx lint-staged"
再在 lint-staged 配置中指定：
- 只检查本次提交改动的
.ts文件：运行eslint --fix和tsc --noEmit - 只检查改动的
.md：运行markdownlint - 所有检查通过才允许提交；失败则中断，不生成 commit 对象
这不会拖慢你写代码的速度，但能拦下 80% 的低级提交错误。别让 CI 承担本该由本地完成的过滤职责。
分支命名和 PR 标题不是风格问题，是检索效率问题
当某天你要查“用户注销时 token 是否被清除”，你会搜 git log --grep "logout"，还是翻 37 个叫 dev、temp-fix、mybranch 的分支？
统一使用语义化前缀：
-
feat/login-flow（功能开发） -
fix/api-timeout（紧急修复） -
refactor/cache-layer（重构） -
chore/ci-upgrade（运维类）
对应 PR 标题也保持一致：fix(api): handle 504 timeout in /auth/logout。GitHub/GitLab 的搜索、Jira 的自动关联、甚至你明年回看自己的 PR 列表，都依赖这个最小但关键的结构。
最常被忽略的一点：哪怕只是改一行 CSS，也要走完整流程——独立分支、语义化提交、带描述的 PR。所谓“规范化”，不是给大功能设门槛，而是让小改动也能在未来被准确定位。
