很多人觉得 Git 分支管理很复杂，实际上只要抓住几个核心原则，就不会再“乱开分支”。这篇文章记录一套比较实用的日常分支管理方式。
先说结论
最适合大多数个人项目和小团队的模式，是：
main：稳定主分支dev：开发分支feature/*：功能分支fix/*：修复分支hotfix/*：线上紧急修复
不要一上来就开很多分支，关键是要有清晰的职责边界。
1. 不要把主分支当“试验场”
main 或 master 应该始终保持可发布状态。也就是说，代码合并到主分支之前，至少需要经过一次检查和必要的测试。
如果你和别人要协作，主分支一旦有问题，会直接影响发布。保持稳定非常关键。
2. 功能分支应该短命
新需求或新特性，最好基于 dev 或 main 新建分支，例如：
1 | git checkout -b feature/blog-theme |
功能分支的好处是：
- 代码变更单独管理
- 便于回看和 review
- 不影响其他开发中的功能
记住一点：功能分支最好在功能完成后尽快合并，避免长期存在导致维护成本上升。
3. 提交前先清一遍状态
在提交前，最好检查：
1 | git status |
这一步看似简单，但能避免很多“提交了半截代码”之类的问题。特别是前端和博客类项目，经常容易出现未保存文件、调试代码、临时日志残留的情况。
4. 提交信息要准确
提交信息不是随便写一个“update”，最好用准确的描述：
1 | git commit -m "fix: resolve theme config loading issue" |
如果你以后回看历史提交，清晰的提交信息会让你省很多时间。
5. 合并前做一次思考
不是所有分支都应该直接合并。尤其是当改动范围比较大时，需要评估：
- 是否影响已有功能
- 是否需要测试
- 是否有兼容性问题
- 是否有回滚成本
这部分其实和代码质量无关，而是工程管理的能力。对于个人项目来说，分支管理不是“为了管理而管理”，而是为了让自己更轻松地维护项目。
6. 个人项目也值得建立规则
很多人以为 Git 规则只适合团队，其实不是。即使是一个人维护的博客项目，也可以建立一些基本规则：
- 不在主分支直接写实验性代码
- 重要修改单独开分支
- 提交前注意质量
- 发布前在本地验证
这样做之后，你对项目的控制感会明显增强。