很多个人项目的仓库长这样：一次 init，然后一条 update 或者 fix，最后半年没有提交。等到想改某个功能时，已经说不清上次到底改了什么。版本管理对个人项目的价值不是「多人协作」，而是让过去的自己给现在的自己留线索。
一个提交只做一件事
feat: 项目卡片支持按技术栈筛选
fix: 修复移动端菜单关闭后页面仍被锁定
style: 统一卡片描边与圆角拆开提交的好处不是好看，而是可回滚。一个提交里混了「改样式 + 加功能 + 修 bug」，出问题时你只能整个撤回。
个人项目里这条同样成立，只是粒度可以松一些：一次提交控制在半小时内的工作量就够。
提交信息写「为什么」
update、修改、111 这类信息等于没写。好的提交信息回答两件事：做了什么、为什么这么做。
fix: 星空在页面切到后台后继续绘制
visibilitychange 只监听了首次加载，
ClientRouter 切换页面后监听器被重复注册。
改为在 astro:page-load 时统一注册，before-swap 时清理。第二段才是关键：半年后你看到这段，会立刻明白当时踩了什么坑。
分支不是团队专属
即使只有一个人，也建议至少分两类：
main始终是能部署的状态；- 新功能或大改动开一个短分支，做完再合。
这样做最大的收益是：随时可以放弃一次尝试。写到一半发现方向不对，切回 main 就回到干净状态，不用手动删一堆代码。
别提交生成物
node_modules/、dist/、.astro/ 都不该进仓库。它们可以随时重建，提交进去只会让 diff 变脏、仓库变大。
dist/ 尤其要小心：有人为了部署方便把构建产物也提交了，结果每次构建都产生几百个文件变更，真正的代码改动被淹没在里面。
提交前跑一次构建
npm run check && npm run build这一步能拦住大部分「本地能跑、线上白屏」的问题。把它写进习惯，比事后排查便宜得多。有 CI 的话更应该让 CI 做这件事，失败就不部署。
用 tag 标记可回忆的节点
上线、交作业、比赛提交这类节点打个 tag：
git tag -a v1.0 -m "首个公开版本"以后想回看「当时交上去的到底是什么样」，一条命令就能切过去，不用在一堆提交里猜。
最小可执行清单
- 提交信息带类型前缀，正文写原因
- 一个提交只做一件事
main永远可部署- 不提交生成物与密钥
- 提交前跑构建
- 重要节点打 tag
这六条不需要任何工具或流程，但能覆盖个人项目 90% 的「我当时到底改了什么」问题。