主分支#

• main（或 master）：线上稳定分支。每一次正式发布通常都来自这里，并通过 Tag 标记版本。
• develop：日常集成分支。新功能开发完成后会合回 develop，用于持续集成与联调。

临时分支#

• feature/*：功能分支，从 develop 拉出，完成后合回 develop。
• release/*：发布分支，从 develop 拉出，用于发版前的收尾（修 bug、改版本号、补文档等），最终合到 main 并回灌 develop。
• hotfix/*：紧急修复分支，从 main 拉出，修复线上问题，最终合到 main 并回灌 develop。

1) 开发新功能：feature 分支#

目标：不污染 develop，开发完成后再合并。

1
git switch develop
2
git pull
3
git switch -c feature/user-profile

功能完成后发起 PR 合并到 develop。合并完成后可以删除 feature 分支：

1
git switch develop
2
git pull
3
git branch -d feature/user-profile

2) 准备发版：release 分支#

目标：冻结需求，专注发版质量；同时不阻塞 develop 的后续开发。

1
git switch develop
2
git pull
3
git switch -c release/1.3.0

在 release/1.3.0 上通常会做：

• 修复发版相关 bug
• 调整版本号
• 补发版说明（changelog）

确认发布后：

1. 合并到 main
2. 在 main 上打 tag
3. 把 release 的改动回灌到 develop

1
git switch main
2
git pull
3
git merge --no-ff release/1.3.0
4
git tag -a v1.3.0 -m "release v1.3.0"
5
git push --follow-tags
6

7
git switch develop
8
git pull
9
git merge --no-ff release/1.3.0
10
git push

发布完成后删除发布分支：

1
git branch -d release/1.3.0

3) 线上紧急修复：hotfix 分支#

目标：以最短路径修复线上，不等待 develop 的合并节奏。

1
git switch main
2
git pull
3
git switch -c hotfix/1.3.1

修复完成后：

1. 合并回 main 并打 tag
2. 回灌 develop（否则下次发布可能把 bug 又带回来）

1
git switch main
2
git pull
3
git merge --no-ff hotfix/1.3.1
4
git tag -a v1.3.1 -m "hotfix v1.3.1"
5
git push --follow-tags
6

7
git switch develop
8
git pull
9
git merge --no-ff hotfix/1.3.1
10
git push

分支命名约定#

• feature/<ticket>-<desc>
• release/<version>
• hotfix/<version>

明确 ticket（Jira/禅道/飞书任务）能减少“这分支是干嘛的”的沟通成本。

合并策略建议#

• 日常 feature 合并建议走 PR + review
• 合并时倾向使用 --no-ff 保留分支合并节点，方便追溯一个 feature 的整体生命周期
• 需要线性历史（rebase）也可以，但要团队一致，且注意不要 rebase 已推送且多人协作的分支

Tag 与版本号#

• 发布分支/热修分支最终都应该落到 main，并在 main 打 tag
• tag 建议使用 vX.Y.Z（语义化版本），长期会非常省事：定位问题、回滚、对比版本都更直观

适合#

• 有明确“发版”概念的软件：需要版本号、发布窗口、变更可追溯
• 需要同时并行多个功能开发，还要保证某个版本稳定交付
• 线上问题需要快速热修，且修复必须被未来版本继承

不太适合#

• 小团队/个人项目：分支成本大于收益
• 强 Trunk-Based（主干开发）文化的团队：更倾向短分支 + 快速合并到主干 + 高频发布
• 非常高频发版（比如一天多次发布）：GitFlow 的 release 分支会显得偏重