Git 分支模型与团队工作流

三种主流模型

Git Flow（老牌、重）：长期存在 master（生产）、develop（开发）两条主分支，功能分支 feature/、发布分支 release/、热修复 hotfix/*。规则严谨但分支多，适合有版本发布周期的传统软件。

GitHub Flow（轻量、最流行）：只有一条长期分支 main，任何改动都从 main 拉 feature 分支，PR 评审通过后合并并立即部署。简单清晰，适合持续交付的 Web 项目。

GitLab Flow：折中——main 之外按环境设 pre-production、production 分支，代码随分支向上游流动，适合多环境部署。

团队当前约定（GitHub Flow 改良）

main          受保护，只接受 PR，始终可部署
feature/xxx   从 main 切出，命名带任务号：feature/JIRA-123-post-search
fix/xxx       缺陷修复
hotfix/xxx    生产紧急修复，从 main 切，修完回合 main 并立即发布

流程：拉分支 → 小步提交 → push 发 PR → CI 自动跑 lint/测试 → 至少一人 review → squash merge（主干历史干净）。

提交信息约定

采用 Conventional Commics：

feat: 新增文章搜索框
fix: 修复评论分页页码错乱
refactor: 抽取 Prisma 错误处理工具
docs / style / test / chore

好处是语义明确，还能自动生成 changelog。

高频排错命令

git reflog                 # 所有操作历史，误删/rebase 搞砸的救命稻草
git reset --soft HEAD~1    # 撤销最后一次提交，保留改动
git stash -u               # 临时存放含未跟踪文件的改动
git cherry-pick <commit>   # 拣单个提交
git revert <commit>        # 用新提交撤销，公共分支首选

铁律：已经 push 到共享分支的提交，不要 rebase/reset 改写历史，用 revert。