docs(开发日记): 添加GitFlow学习文档

介绍GitFlow分支模型的核心概念、标准流程和团队落地建议，帮助团队理解分支协作规范

src/content/posts/开发日记/GitFlow学习.md

@@ -0,0 +1,194 @@
+---
+title: 开发日记/GitFlow学习
+published: 2026-01-10T00:21:42
+description: ''
+image: ''
+
+draft: false 
+lang: ''
+category: '开发日记'
+---
+# GitFlow 学习：一套分支协作“规矩”的来龙去脉
+
+这两天为了把团队协作流程梳理清楚，我系统看了一遍 GitFlow。它不是某个命令，也不是 Git 的内置功能，而是一套“怎么分支、怎么合并、怎么发版、怎么修线上”的协作约定。
+
+它的优点是清晰、可控、可复用；缺点是流程偏重、分支偏多。适不适合，取决于团队规模、发版节奏和项目类型。
+
+## GitFlow 解决的核心问题
+
+在多人协作里，常见的冲突不是代码冲突，而是“节奏冲突”：
+
+- 你在开发新功能，另一个人要紧急修线上 bug
+- 产品要在本周发一个稳定版本，但下周的大需求已经在开发中
+- 版本需要打 Tag、回滚、追溯某次发布包含哪些改动
+
+GitFlow 做的事情就是把这些“节奏”通过分支模型固定下来，让每个人都知道：
+
+- 哪个分支代表线上稳定版本
+- 哪个分支代表日常集成
+- 新功能、发版、紧急修复分别从哪里来、往哪里去
+
+## 分支模型：两条主干 + 三类临时分支
+
+### 主分支
+
+- `main`（或 `master`）：线上稳定分支。每一次正式发布通常都来自这里，并通过 Tag 标记版本。
+- `develop`：日常集成分支。新功能开发完成后会合回 `develop`，用于持续集成与联调。
+
+### 临时分支
+
+- `feature/*`：功能分支，从 `develop` 拉出，完成后合回 `develop`。
+- `release/*`：发布分支，从 `develop` 拉出，用于发版前的收尾（修 bug、改版本号、补文档等），最终合到 `main` 并回灌 `develop`。
+- `hotfix/*`：紧急修复分支，从 `main` 拉出，修复线上问题，最终合到 `main` 并回灌 `develop`。
+
+## 标准流程：从开发到发布，再到紧急修复
+
+### 1) 开发新功能：feature 分支
+
+目标：不污染 `develop`，开发完成后再合并。
+
+```bash
+git switch develop
+git pull
+git switch -c feature/user-profile
+```
+
+功能完成后发起 PR 合并到 `develop`。合并完成后可以删除 feature 分支：
+
+```bash
+git switch develop
+git pull
+git branch -d feature/user-profile
+```
+
+### 2) 准备发版：release 分支
+
+目标：冻结需求，专注发版质量；同时不阻塞 `develop` 的后续开发。
+
+```bash
+git switch develop
+git pull
+git switch -c release/1.3.0
+```
+
+在 `release/1.3.0` 上通常会做：
+
+- 修复发版相关 bug
+- 调整版本号
+- 补发版说明（changelog）
+
+确认发布后：
+
+1. 合并到 `main`
+2. 在 `main` 上打 tag
+3. 把 release 的改动回灌到 `develop`
+
+```bash
+git switch main
+git pull
+git merge --no-ff release/1.3.0
+git tag -a v1.3.0 -m "release v1.3.0"
+git push --follow-tags
+
+git switch develop
+git pull
+git merge --no-ff release/1.3.0
+git push
+```
+
+发布完成后删除发布分支：
+
+```bash
+git branch -d release/1.3.0
+```
+
+### 3) 线上紧急修复：hotfix 分支
+
+目标：以最短路径修复线上，不等待 `develop` 的合并节奏。
+
+```bash
+git switch main
+git pull
+git switch -c hotfix/1.3.1
+```
+
+修复完成后：
+
+1. 合并回 `main` 并打 tag
+2. 回灌 `develop`（否则下次发布可能把 bug 又带回来）
+
+```bash
+git switch main
+git pull
+git merge --no-ff hotfix/1.3.1
+git tag -a v1.3.1 -m "hotfix v1.3.1"
+git push --follow-tags
+
+git switch develop
+git pull
+git merge --no-ff hotfix/1.3.1
+git push
+```
+
+## 团队落地建议：不然 GitFlow 会变成“形式主义”
+
+### 分支命名约定
+
+- `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 分支会显得偏重
+
+## 常见踩坑点
+
+- `develop` 长期不稳定：如果大家把“坏掉也没关系”的心态带进 `develop`，那 release 就会变成灾难收尾现场
+- release 分支拖太久：发版窗口越长，回灌冲突越大；release 建议短周期
+- hotfix 没回灌 develop：短期看修好了，长期会在下次发布被“复活”
+- 过度流程化：所有改动都走 release/hotfix，导致流程负担极高，最后大家反而绕流程
+
+## 和 GitHub Flow / Trunk-Based 的简单对比
+
+- GitFlow：强调“版本管理”和“并行节奏”，清晰但偏重
+- GitHub Flow：通常只有 `main` + feature 分支，合并即部署，适合持续交付
+- Trunk-Based：极短生命周期分支（甚至直接主干），依赖 CI/CD 与 feature toggle，效率高但要求工程化更强
+
+## 小结
+
+GitFlow 的本质不是“分支越多越专业”，而是把团队协作里最难的三个问题拆开解决：
+
+- 日常集成（`develop`）
+- 稳定发布（`release/*` -> `main` + tag）
+- 线上热修（`hotfix/*` -> `main` + 回灌 `develop`）
+
+如果团队发版节奏明确、需要追溯和稳定性，GitFlow 很好用；如果项目更追求快速交付与高频发布，GitHub Flow 或 Trunk-Based 可能更适合。
+
+## 参考
+
+- https://blog.csdn.net/sunyctf/article/details/130587970
+#