Git 工作流最佳实践

Git 是每个开发者的日常工具，但用得好和用得差不多之间差距很大。这篇文章总结了我从个人项目到团队协作中积累的 Git 最佳实践。

Commit Message 规范

一个好的 commit message 能让你三个月后仍然看懂当时做了什么。我推荐 Conventional Commits 格式：

<type>(<scope>): <short summary>

<body>

<footer>

常用的 type：

feat：新功能
fix：Bug 修复
refactor：重构（不改变功能）
docs：文档变更
style：代码格式（空格、分号等）
test：添加或修改测试
chore：构建、依赖等杂项

                ✅ 好的 commit message：

                fix(auth): 修复 Token 过期后无限刷新的问题

                ❌ 差的 commit message：

                fix bug · update · 改了点东西

分支策略

对于个人项目和小团队，我推荐简化版的 Trunk-Based Development：

main：始终可部署的稳定分支
feat/xxx：新功能开发分支
fix/xxx：Bug 修复分支

分支命名用英文小写 + 连字符，简短描述变更内容：feat/watermark-support、fix/login-redirect。

每个分支只做一件事。如果一个分支改了 5 个不相关的功能，review 的人会很痛苦，rollback 的时候也会很麻烦。

PR 的最佳实践

写 PR 描述不只是为了别人，也是为了你自己。一个好的 PR 模板：

## What
简述这个 PR 做了什么

## Why
为什么要这样改

## How
实现方案简述（如有替代方案也说明为什么没选）

## Screenshots / Test
截图或测试说明（UI 改动必加截图）

另外，尽量保持 PR 小巧——200 行以内是最容易 review 的。 大功能可以拆成多个小 PR 逐步合并。

善用 .gitignore

在项目开始时就配好 .gitignore，避免把 node_modules、.env、IDE 配置文件、系统临时文件提交进去。很多问题都是因为某个人的本地配置文件被提交上去惹出来的。

Git Rebase vs Merge

这是新手最容易困惑的地方。简单原则：

个人分支用 rebase：保持提交历史干净整洁
公共分支用 merge：不要改写别人可能正在基于其工作的提交

# 在 feat 分支上把 main 的最新改动 rebase 进来
git fetch origin
git rebase origin/main

# 解决冲突后
git push --force-with-lease  # 注意：只在自己的 feat 分支上 force push

Git 是一个工具，不是目的。好的工作流应该让你的开发更顺畅，而不是增加负担。从简单的开始，遇到问题了再逐步完善。