Git 分支管理的个人实践：小项目也要有规矩

一个人写代码，Git 的用途看起来就是「存档」，我也这么用了大半年。 后来有两次改坏了想找之前的版本，翻提交历史全是「update」「fix」「又改了一版」， 根本对不上哪个是哪个。痛过之后整理了一套适合个人项目的做法。

一、分支怎么分

个人项目不需要复杂的分支模型，但至少三条：

• main：永远保持可运行，只放完成的功能。
• dev：日常开发在这里，允许暂时跑不通。
• feat/xxx：单个功能或实验性改动，做完就合回 dev 再删掉。

好处是想回退某个功能时，能找到它对应的独立分支，不影响其他部分。

二、提交信息写什么

固定一个格式，看历史时一眼能定位：

feat: 新增用户登录表单校验
fix: 修复分页越界导致的空指针
docs: 补充部署说明
chore: 更新依赖版本

类型加英文冒号加空格，描述用中文没关系，关键是说清楚做了什么。 「update」这种信息，三个月后等于没写。

三、提交粒度

一个提交只做一件事。写完表单校验就单独提交，不要把顺手改的界面配色也塞进去。 需要回滚的时候，粒度细才回得干净。

# 只暂存相关的改动，而不是 git add .
git add src/login.js
git commit -m "feat: 登录表单增加必填校验"

# 提交前看一眼改了什么
git status
git diff

四、回滚的几种情况

# 改乱了还没提交，丢弃工作区改动
git checkout -- 文件名

# 已经 add 但没 commit，退回暂存区
git reset HEAD 文件名

# 最近一次提交写错了信息（还没推送到远程）
git commit --amend -m "更正后的信息"

# 撤销某个已推送的提交，生成一个反向提交，历史保持干净
git revert <commit-id>

个人习惯：已经推送出去的历史尽量用 revert 而不是 reset， 避免改写历史带来的同步麻烦。

五、随手做的几件小事

• 项目一创建就写好 .gitignore，别等误提交了再去清理。
• 做完一个功能就打个标签，git tag v0.2.0，回溯版本省事很多。
• 每天收工前把 dev 推到远程，本地磁盘坏了不至于全丢。

这些规矩都不复杂，重要的是形成固定动作。现在翻历史基本能还原当时的思路， 对我来说这就够了。