Git 工作流最佳实践：从 commit 规范到分支策略

1. Commit Message 规范：Conventional Commits

Conventional Commits 是目前最流行的 commit message 规范，被 Angular、Vue、React 等主流开源项目广泛采用。它的核心格式如下：

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

其中 type 是最关键的部分，常见的类型包括：

好的 commit message 示例：feat(auth): 添加微信扫码登录支持、fix(cart): 修复数量为 0 时仍可下单的问题。配合 commitlint + husky，可以在 commit 时自动校验格式，从源头杜绝不规范的提交。

2. 分支策略：Git Flow vs Trunk-based

分支策略是团队协作的核心。目前主流的两种策略各有利弊，选择哪种取决于团队规模、发布节奏和 CI/CD 成熟度。

个人建议：如果你的团队小于 10 人，且有完善的 CI/CD 流水线，Trunk-based 是更好的选择。它能减少合并冲突、加快交付速度。大型团队或需要同时维护多个版本的项目，Git Flow 更稳妥。

3. Rebase vs Merge：永恒的争论

这大概是 Git 社区里最具争议的话题之一了。两者的核心区别在于对提交历史的处理方式。

# Merge：保留分支历史，产生合并 commit
git checkout main
git merge feature/login

# Rebase：将分支提交「嫁接」到目标分支顶部，线性历史
git checkout feature/login
git rebase main
git checkout main
git merge feature/login  # fast-forward

黄金法则：永远不要对已经推送到远端的公共分支执行 rebase。在自己的 feature 分支上随便 rebase，合并到 main 时用 merge 或 squash merge，这是大多数团队的最佳实践。

4. 常见 Git 踩坑与急救指南

在日常开发中，总会遇到各种 Git 翻车现场。以下是一些高频场景和解决方案：

# 从暂存区移除但保留本地文件
git reset HEAD -- .env
git commit --amend

# 如果已经 push，用新 commit 删除
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "chore: 移除误提交的 .env 文件"

# 放弃 merge
git merge --abort

# 放弃 rebase
git rebase --abort

# reflog 是你的救命稻草
git reflog
# 找到丢失的 commit hash
git checkout <hash>
# 或者创建新分支恢复
git branch recovery <hash>

5. 团队 Git 工作流落地建议

规范再好，落不了地也是白搭。以下是我在多个团队中推行 Git 规范的实战经验：

• 工具链强制约束：用 husky + commitlint + lint-staged 在 commit 时自动校验，不通过就不让提交，比口头约定管用一百倍。
• Code Review 必须通过：所有代码必须通过 PR/MR 合并，至少一人 approve。这不仅是代码质量保障，也是知识共享的重要途径。
• 分支保护规则：main/develop 分支设置保护，禁止直接 push，只能通过 PR 合并。
• 自动化 CHANGELOG：基于 Conventional Commits，用 standard-version 或 changelogen 自动生成 CHANGELOG，省时省力。