GitFlow的使用和注意

GitFlow-定义

在企业开发中，团队协作通常不会直接在 main 或 master 上开发，而是会遵循一套分支管理流程。

所谓 GitFlow，就是最经典的一种 基于分支的工作流（branching model）。它由 Vincent Driessen 在 2010 年提出，用来规范团队如何创建、合并和管理分支。

GitFlow 定义了分支类型和分工：每种分支有明确职责，整个流程看起来就像流水线。

各个分支

主分支

main（或 master）

• 线上正式运行的代码。
• 只能从 release 或 hotfix 分支合并。
• 始终保持稳定可发布状态。

develop

• 主开发分支，所有功能分支的基础。
• 开发完成的功能先合并到 develop，不会直接影响线上。

辅助分支

feature/\*

• 用来开发新功能。
• 从 develop 拉出来，开发完后再合并回 develop。
• 命名：feature/login-api、feature/cart-page

release/\*

• 用来准备一次版本发布。
• 从 develop 拉出来，做测试、修复 bug、调整小问题。
• 测试通过 → 合并回 main 和 develop，并打 tag。
• 命名：release/1.0.0

hotfix/\*

• 紧急修复线上 bug。
• 从 main 拉出来，修复后再合并回 main 和 develop。
• 命名：hotfix/fix-login-bug

流程图

main ───────────●─────●──────────────●───────▶
                 ↑     ↑
                /       \
       hotfix──●         ●──release
               ↑          \
develop ──────●───────────●─────────▶
                \          \
                 ●──feature ●──feature

总结

GitFlow = 一种 Git 分支管理流程，主要分为：

• main（线上）
• develop（开发主干）
• feature（功能开发）
• release（发布前测试）
• hotfix（线上修复）

它适合 版本发布周期长、多人协作的大型项目。 但对于互联网敏捷项目，现在很多公司改用 GitHub Flow（只有 main + feature 分支） 或 GitLab Flow（结合 CI/CD）。

场景模拟与解决

那下面我们就来模拟一些场景，一起来练习下，熟悉下，该怎么操作，毕竟实际出真知，动手实践是成长最快的方式。

clone分支

现在有一个主分支，可能叫 master 或者 main。

main

我们需要从线上拉取下来。

git clone git@gitee.com:sky-lord/aaa-test.git

git clone 命令默认会克隆远程仓库的所有分支的代码和历史，但它在你的本地工作目录中只为你创建一个分支，通常是默认分支（如 main 或 master）。

如果你想在克隆之后直接进入一个特定的分支（而不是默认分支），可以使用 -b 或 --branch 参数来指定。

git clone -b <分支名> <仓库地址>

git clone -b dev git@github.com:username/my-project.git

合并

代码写完，测试完毕后，推送到远程后，比如：推送 feature 分支后是否要发 merge request？

答案：在团队协作中，通常需要。

但是否必须，取决于团队是否使用 代码评审（Code Review） 流程。主要有2种情况：

远程合并

团队协作，使用代码评审（推荐的 Git Flow 实践）

git checkout -b feature/login develop
# 基于 develop 分支创建一个名为 feature/login 的新本地分支，并立即切换到该分支。

开发完成后，推送到远程

git push -u origin feature/login

在远程仓库（GitLab / GitHub）上创建 Merge Request / Pull Request

• 目标分支：develop
• 目的是：
  • 让同事 review 代码
  • 自动触发 CI/CD 流水线（测试、静态检查等）
  • 由项目负责人批准后合并

审核通过后，进行合并(这一步通常是在网页上进行操作)

merge feature/login → develop

在标准 Git Flow 团队协作中，推送 feature 分支后需要发 Merge Request，因为这是团队代码质量控制的关键步骤。

本地合并后再推送

如果是你一个人维护项目，或者团队非常小（例如两个人配合开发）：

你也可以直接在本地合并到 develop：

git checkout develop
git merge --no-ff feature/login

然后推送：

git push origin develop

最后，删除本地和远程的 feature 分支。

这种情况下，不需要发 merge request， 因为你自己负责审查和发布。

扩展--no-ff

上述中的--no-ff是什么意思呢？

--no-ff 表示 禁用快进（Fast-Forward）合并， 强制创建一个新的 Merge Commit（合并提交）。

这让 Git 历史中能清楚地看到：“这里曾经合并过一个 feature 分支”。

一个例子：

假设我们现在有这样的分支结构：

A --- B --- C (develop)
         \
          D --- E (feature/login)

使用普通合并（默认 fast-forward）

git checkout develop
git merge feature/login

结果就是

A --- B --- C --- D --- E (develop)

• 不会创建新的 commit。

• 历史看起来像一条线。

• 但你无法看出 feature/login 这个分支存在过。

使用--no-ff进行合并

git checkout develop
git merge --no-ff feature/login

结果

A --- B --- C ------------- M (develop)
         \                 /
          D --- E (feature/login)

GitFlow-扩展

线上紧急修复（hotfix）

• 如果线上 main 出了 bug：
  • 从 main 拉出 hotfix/*
  • 修复完成后合并回 main 和 develop

为什么要合并回 develop？

因为 develop 可能比 main 超前，已经有很多新功能了，但这个 bug 修复必须保证 未来版本也带上。 否则，等下次发布时，新功能合并到 main，又会把旧的 bug 带回来。

develop 上的某些提交点会和 main 上完全一样，因为 hotfix 必须回流。

这样才能保证：线上修过的 bug 不会在下一个版本又出现。

develop和main的关系

• develop 会比 main 多出很多提交（功能开发、测试提交等）。
• 只有当要发布时，才会从 develop 拉出 release → 稳定后合并回 main。
• 因此，main 上的每个版本号 tag（比如 v1.0.0, v1.1.0），都对应 develop 历史中的某个稳定节点。

可以这么理解：

• develop：记录了“开发的全过程”，提交很多，可能包含不稳定的代码。
• main：只挑选出 develop 中那些稳定可发布的里程碑节点。

main     ---●────────────●──────────●────────▶
             v1.0.0       v1.1.0     v1.2.0
              ↑             ↑          ↑
develop  ---●───●──●──●───●──●──●────●──●────▶
             功能1  功能2   修复   功能3  功能4

开发中，线上（main）出 bug

假设当前情况：

• 你在 develop 上开发新功能（可能一堆代码还没完成，甚至不稳定）。
• 突然线上用户反馈一个严重 bug（在 main 里）。

1.从 main 拉出 hotfix 分支

git checkout main
git checkout -b hotfix/fix-login-bug

2.修复 bug & 提交代码

git commit -am "fix: login bug"

自动将所有已被 Git 跟踪的文件的修改（modified files）添加到暂存区，并提交一次，提交信息为 "fix: login bug"。

等同于 git add + git commit -m "xx"

3.合并到 main

git checkout main
git merge hotfix/fix-login-bug
git tag -a v1.0.1 -m "Hotfix: login bug"
git push origin main --tags

上线发布新版本（例如 v1.0.1）。

这是一个选项，表示：同时推送所有本地的标签（tags）到远程仓库。

• Git 的 tag 通常用于标记发布版本，比如 v1.0.0、v2.1.3。
• 默认情况下，git push origin main 不会推送标签，只推送分支上的提交。
• 加上 --tags 后，所有通过 git tag v1.0.0 创建的标签都会被推送到远程。

4.合并回 develop

git checkout develop
git merge hotfix/fix-login-bug
git push origin develop

确保开发主干也包含这个 bug 修复，不会在未来新版本里“又复活”。

5.删除 hotfix 分支

git branch -d hotfix/fix-login-bug