Git 分支习惯该怎样尽早建立
· 阅读需 2 分钟
2013 年开始接触 Git 的开发者越来越多，但很多人最初只会在 master 上一路提交。代码虽然也能工作，可一旦同时改两个需求、修一个线上问题，仓库马上就会变得很难整理。
分支的价值不在“高级”，而在隔离改动
小团队或者个人项目最容易遇到的问题是：一个功能还没做完，另一个紧急修改又要马上插进来。如果所有改动都堆在同一条线上，最后往往是提交记录乱、回退困难、合并也不清楚。
这时候哪怕只养成最基本的分支习惯，也会轻松很多：
- 新功能单独开分支
- 修 bug 单独开分支
- 完成后再合回主线
最基础的用法已经够实用
git checkout -b feature/login-form
# 开发并提交
git checkout master
git merge feature/login-form
这套流程今天看很普通，但放回 2013 年，它已经足够帮助很多项目摆脱“所有代码都混在一起”的状态。
分支命名最好一眼能看懂用途
刚开始时没必要追求复杂规范，但至少应该让名字带出意图。像 feature/、fix/、experiment/ 这种前缀就很实用，因为后来回头看历史时，能马上知道当时开这个分支是为了解什么问题。
相反，像 test1、new、abc 这种名字短是短，过两周基本就没有任何信息量了。
不要让分支活得太久
很多初学者第一次用分支时，还会出现另一个问题：分支开了之后一直不合并，最后和主线差别越来越大。这样一来，分支本来是为了减少混乱，结果反而让合并变得更痛苦。
更好的做法是把改动拆小一点，让分支尽量短命。一个分支只处理一件事，做完就合并，仓库会清楚很多。
小结
Git 分支在 2013 年对很多开发者来说并不只是“进阶玩法”，而是让代码协作开始真正有秩序的第一步。越早形成清晰的分支习惯，后面的提交、合并和回退就越容易稳定下来。