适合个人项目的 Git 工作流

个人项目不需要照搬大型团队的分支模型，但也不应该把所有修改都堆在一个无法解释的提交里。一套轻量工作流的目标，是让几个月后的自己仍然能够理解发生过什么。

保持主分支随时可发布

main 分支只保留已经验证过的内容。小范围修改可以直接在主分支完成；涉及多文件或可能中断的功能，则创建一个短期分支。

git switch -c feature/article-archive

功能完成并验证后再合并，随后删除短期分支。个人项目不需要长期保留大量分支，因为真正有价值的历史已经存在于提交记录中。

一个提交只表达一件事

好的提交应该能够独立解释，也应该尽量可以独立回退。修改样式、修复构建错误和新增文章通常是三件不同的事情，适合分别提交。

feat: add article archive page
fix: preserve cover image ratio on mobile
docs: add deployment notes

提交信息不必追求复杂格式，但动词和范围应该清楚。相比“update”或“修改一下”，明确说明结果会节省以后排查问题的时间。

提交前只做三项检查

每次提交前，我至少确认三件事：

1. git diff 中没有密钥、临时日志或无关文件；
2. 项目能够完成一次生产构建；
3. 关键页面或核心命令可以正常运行。

对于静态网站，最基本的检查就是：

npm run build

构建通过不能证明所有页面都完美，但能够提前发现类型错误、失效的内容字段和无法生成的路由。

用标签标记公开版本

当网站完成一次值得记录的更新时，可以创建标签：

git tag -a v1.0.0 -m "first public release"
git push origin v1.0.0

标签让“当前线上版本对应哪次提交”变得清晰。以后出现问题时，可以快速比较版本差异，也可以从已知稳定版本重新部署。

简单规则更容易坚持

个人工作流不需要为不存在的协作问题增加流程。主分支可发布、提交内容单一、发布前完成构建，这三个规则已经覆盖了大多数风险。

工具的意义是保留上下文，而不是制造仪式。只要流程足够简单，就更有可能在每次修改时真正执行。