Git分支管理：一个人的项目怎么用分支才不乱

很多个人开发者觉得Git分支是团队才用的东西，自己一个人写代码，直接在main上改就行了。我以前也这么想，直到有一次改崩了线上网站，回滚花了两个小时，才下定决心把分支管理学明白。

一个人的项目，分支不用多，三条就够：main、dev、feature/xxx。main是生产分支，永远是可部署的状态。dev是开发分支，日常改代码在这里改。feature/xxx是功能分支，每做一个新功能开一个分支，做完合回dev，确认没问题再合到main。

日常工作流：改代码前，先从dev拉一个feature分支：git checkout -b feature/add-contact-form。改完之后，合回dev：git checkout dev && git merge feature/add-contact-form。测试没问题，合到main：git checkout main && git merge dev。最后推到远程：git push origin main。

这个流程的好处是，main永远是干净的。你在feature分支上改崩了，不影响dev和main。想放弃这个功能，直接删分支就行：git branch -d feature/add-contact-form。比在main上改完发现不行、然后git reset回退干净得多。

commit的写法也有讲究。别写「修改」「更新」「fix」这种废话。好的commit长这样：「fix: 修复移动端导航菜单不收起的问题」或者「feat: 新增联系表单页面」。前缀用feat/fix/docs/style/refactor，是Angular的commit规范，虽然看起来啰嗦，但半年后你回头看git log，一眼就知道每次改了什么。

还有一个救命操作：git stash。改代码改到一半，线上出了bug要紧急修复。你手头的改动还没完成不想commit，但又需要切到main分支修bug。这时候git stash把改动暂存起来，切到main修完bug，再切回来git stash pop恢复。整个过程30秒，比手动存文件到桌面再拷回来靠谱。

tag也很实用。每次上线打一个tag：git tag v1.2.0 && git push origin v1.2.0。线上出了问题，直接git checkout v1.1.9回到上一个版本，比翻commit历史找「上次能用的是哪个」快十倍。

总结一下：一个人的项目，main+dev+feature三支分支，commit写清楚前缀和描述，改到一半要切分支用stash，上线打tag。这些习惯花一天学会，能省你未来无数次「改崩了回不去」的焦虑。

标签： Git 分支管理 开发技巧