分支工作流

这一课你将能做到

1. 画出 Git Flow 与 GitHub Flow 的分支模型图，说出各自适用场景
2. 按 Feature 分支工作流完成「从 main 切出 → 开发 → 合回」的完整节奏
3. 用规范的分支命名（feature/xxx、fix/xxx、hotfix/xxx）让团队一眼看懂

为什么要学

学会了分支操作，不等于会用分支。实际开发中最容易出问题的不是命令不会敲，而是「分支乱」：不知道该在哪改、往哪合、什么时候删。分支工作流（Branching Workflow）就是一套「章法」——告诉团队每种分支的职责、生命周期和合并方向。

面试问「你们项目用的什么分支模型」，答「Git Flow 太重、我们 GitHub Flow」比支支吾吾强一百倍。

先建立图像

两种主流模型对比：

【GitHub Flow（轻量，适合持续部署）】
main ──●──●──────────────●──●───●────────>  (永远可发布)
        \              /   \
         feature/x ───●     feature/y ────●
        (短生命周期，PR 合回即删)

【Git Flow（重量级，适合有版本发布的项目）】
main    ──●────────────────────●──────────>  (只放发布版)
           \                  /
release ────●──●──●──────────●              (发布准备)
             \        /
develop ──●──●──●──●──●──●───●──────────>  (集成分支)
           \        \
feature ────●        hotfix ──●             (从 main 紧急修)

本站 java-nav 用的是 GitHub Flow 风格：main 永远可发布，所有改动通过短生命周期的 feature 分支 + PR 合回。

跟着做

步骤 1：从 main 切出功能分支

git switch main
git pull                          # 确保 main 最新
git switch -c feature/course-search

分支命名规范（团队约定）：

• feature/xxx 新功能
• fix/xxx 修 bug
• hotfix/xxx 紧急修复（从 main 直接切）
• docs/xxx 纯文档
• refactor/xxx 重构

步骤 2：在功能分支上开发并小步提交

# 改代码...
git add src/search/SearchController.java
git commit -m "feat(search): 新增课程搜索接口"

# 再改一些...
git add src/search/SearchService.java
git commit -m "feat(search): 实现搜索结果高亮"

# 再改...
git commit -m "test(search): 补充搜索接口单元测试"

原则：小步提交，每个 commit 只做一件事。这样既方便 review，也方便出问题时二分定位。

步骤 3：定期同步 main（避免冲突爆炸）

功能开发了几天，main 上别人合了新代码，你要及时同步：

git switch main
git pull
git switch feature/course-search
git merge main                    # 把 main 合进功能分支
# 解决冲突（如果有）...
git add .
git commit

也可用 git rebase main（历史更干净，但初学者先用 merge 更稳妥）。

步骤 4：推送并发起 PR

git push -u origin feature/course-search