Git 工作流实战：从提交规范到版本存档

Git 人人会用，但"用得好"是另一回事。这篇是我实践下来最有效的一套工作流——从日常提交到发布存档，每一条都有明确理由。

提交信息：类型 + 范围 + 描述

规范化的提交信息让日志可读、可搜索、可自动生成 changelog：

feat(editor): 支持图片上传
fix(auth): 修复登录后跳转丢失 from 参数
refactor(header): 抽取移动端菜单为独立组件
perf(posts): 列表页跳过全文渲染

常用类型：feat 新功能 / fix 修复 / refactor 重构 / perf 性能 / docs 文档 / style 格式 / chore 工具。

要点：一次提交只做一件事，描述用动词开头（"支持""修复""抽取"），让 3 个月后的自己能秒懂。

小步提交，而不是攒大招

最常见的坏习惯是攒一大堆改动再提交。小步提交的好处：

1. 出 bug 能精确定位到哪次改动；
2. git bisect 二分查找更有效；
3. 代码评审（如果团队用）容易逐个 commit 看。

git add components/EditorForm.tsx
git commit -m "feat(editor): 增加本地图片上传"
git add lib/markdown.ts
git commit -m "refactor(markdown): 抽出 slugify 工具"

重构前：先打 tag 存档

重构是有风险的，尤其大范围改 UI。动手前先建一个存档点，随时能回到安全状态：

# annotated tag 带信息，比轻量 tag 更推荐
git tag -a pre-ui-refactor -m "UI 重构前存档：当前样式可用"

# 出问题就回到存档点
git checkout pre-ui-refactor

Tag 的语义是"不可变里程碑"——发布版本、重构前、大改前都值得打一个。

分支策略：够用就好

个人项目/小团队不需要复杂的 Git Flow，三套分支就够：

分支	用途
main	随时可部署的主线
feat/xxx	新功能分支，完成合并回 main
fix/xxx	修复分支

git checkout -b feat/guestbook
# ...开发...
git checkout main
git merge feat/guestbook
git branch -d feat/guestbook   # 合并后删掉

cherry-pick：精准移植单次提交

不想整体合并，只想拿某个提交的改动：

# 把 a1b2c3 那次提交的改动应用到当前分支
git cherry-pick a1b2c3

适合场景：hotfix 在不同分支间同步、从实验分支捞某个好想法。

撤销操作速查

场景	命令	说明
撤销工作区改动	git checkout -- file	危险，丢弃未提交改动
撤销已暂存	git restore --staged file	保留文件改动
修改最近提交	git commit --amend	只改最后一个，别 amend 已推送的
回滚已推送提交	git revert <hash>	生成反向提交，不重写历史
回到存档点	git checkout pre-ui-refactor	配合 tag 使用

重要原则：reset 重写历史，revert 追加反操作——已推送共享的分支永远用 revert。

小结

好用的 Git 工作流就四件事：

1. 规范提交——类型+范围+描述，一次一事；
2. 小步走——频繁提交，别攒大招；
3. 打 tag 存档——重构/发布前留后路；
4. 慎用 reset——共享历史只 revert 不 rewrite。

Git 是工具，规则是习惯——把这几条变成肌肉记忆，比记住所有命令都值钱。