git常见开发工作流之gitglow工作流

Posted 2023-03-01 奇妙之二进制

文章首发于微信公众号：Linux 世界

文章目录

• • 版本管理的挑战
  • Git Flow 是什么？
  • Git Flow 流程图
  • Git Flow Branches
  • 仓库的初始情况
  • Master
  • Develop
  • Feature
  • Release
  • Hotfix
  • 总结

版本管理的挑战

虽然有git这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大的挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：

0. 如何确保始终有一个稳定的分支（主干）？
1. 如何开始一个Feature的开发，而不影响别的Feature？
2. 由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
3. 哪些分支已经合并回了主干？
4. 如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？
5. 线上代码出Bug了，如何快速修复？而且修复的代码要同步到哪些分支?

就像编写代码需要代码规范一样，代码管理同样需要一个清晰的流程和规范，定义一个科学可操作的规范，遵守规范执行即可解决上述问题。

Git Flow 是什么？

2010 年 1 月，在一篇名为 “A successful Git branching model” 的博文中，Vincent Driessen 介绍了一种构建在 Git 之上的软件开发流程规范。通过利用 Git 创建和管理分支的能力，为每个分支设定具有特定的含义名称，并将软件生命周期中的各类活动归并到不同的分支上，实现了软件开发过程不同阶段的相互隔离。这种软件开发的流程被 Vincent 称为 “Git Flow”

Git Flow 流程图

这是 Vincent 博文中的 Git FLow 流程图：从右向左看，从上到下看。

上面的图你理解不了？ 没关系，这不是你的错，我觉得这张图本身有点问题，这张图应该左转90度，大家应该就很用以理解了。但这个图画的很详尽，找不到替代的，含括了所有的情况。

我们来拆解以下上面的图。

Git Flow Branches

Git Flow 的核心就是 Branch，通过在项目的不同阶段对 Branch 的不同操作（包括但不限于 create、merge、rebase 等）来实现一个完整的高效率的工作流程。Git Flow Branches 主要分为两大类：Main Branchs（主分支） 和 Supporting branches（辅助分支）。 其中 Main Branchs 中又包含了 Master 和 Develop，而 Supporting branches 中包含了 Feature、Release、Hotfix 以及其他自定义分支

仓库的初始情况

当我们新建git仓库之后，默认会创建一个主分支也就是master分支，我们要基于master分支创建一个develop分支，develop分支用于保存开发好的相对稳定的功能，master分支和develop分支是仓库的常驻分支，一直会保留在仓库中。

Master

• master 分支上存放的是最稳定的正式版本，并且该分支的代码应该是随时可在生产环境中使用的代码（Production Ready state）。当一个版本开发完毕后，产生了一份新的稳定的可供发布的代码时，master 分支上的代码要被更新。同时，每一次更新，都需要在 master 上打上对应的版本号（tag）
• 任何人不允许在 master 上进行代码的直接提交，只接受其他分支的合入。原则上 master 上的代码必须是合并自经过多轮测试且已经发布一段时间且线上稳定的 release 分支（预发分支）

master分支只能来自 release 分支和hotfix分支的合并。mater分支虽然经过多轮测试，还是没法保证绝对没有bug，所以引入了hotfix分支，见下面。

Develop

• develop 分支是主开发分支，其上更新的代码始终反映着下一个发布版本需要交付的新功能。当 develop 分支到达一个稳定的点并准备好发布时，应该从该点拉取一个 release 分支并附上发布版本号。也有人称 develop 分支为 “integration branch”，因为会基于该分支和持续集成工具做自动化的 Nightly builds

• develop 分支接受其他 Supporting branches 分支的合入，最常见的就是 feature 分支，开发一个新功能时拉取新的 feature 分支，开发完成后再并入 develop 分支。需要注意的是，合入 develop 的分支必须保证功能完整，不影响 develop 分支的正常运行。

Feature

• feature 分支又叫做功能分支，一般命名为 feature/xxx，用于开发即将发布版本或未来版本的新功能或者探索新功能。该分支通常存在于开发人员的本地代码库而不要求提交到远程代码库上，除非几个人合作在同一个 feature 分支开发。

关于这点，ThoughtWorks 洞见上有一篇文章 “Gitflow 有害论” 做了非常有意思的阐述，文章下的评论也异常激烈。也许该文章的名字可能有失偏颇，但文章的本意以及评论传达了一个观点：feature 分支要求足够细粒度以避免成为 long-lived branch，应当小步小步 merge 而不是一次 merge 大量代码

• feature 分支只能拉取自 develop 分支，开发完成后要么合并回 develop 分支，要么因为新功能的尝试不如人意而直接丢弃

Release

• release 分支又叫做预发分支，一般命名为 release/1.2（后面是版本号），该分支专为测试—发布新的版本而开辟，允许做小量级的 Bug 修复和准备发布版本的元数据信息（版本号、编译时间等）。通过创建 release 分支，使得 develop 分支得以空闲出来接受下一个版本的新的 feature 分支的合入
• release 分支需要提交到服务器上，交由 QA 进行测试，并由 Dev 修复 Bug。同时根据该分支的特性我们可以部署自动化测试以及生产环境代码的自动化更新和部署
• release 分支只能拉取自 develop 分支，合并回 develop 和 master 分支

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-f0svmI7a-1675822396936)(https://files.mdnice.com/user/24332/0bf7e950-7f10-4a4d-b4d9-9e90683f3121.png)]

Hotfix

• hotfix 分支又叫热修复分支，一般命名为 hotfix/1.2.1（后面是版本号），当生产环境的代码（master 上代码）遇到了严重到必须立即修复的缺陷时，就需要从 master 分支上指定的 tag 版本（比如 1.2）拉取 hotfix 分支进行代码的紧急修复，并附上版本号（比如 1.2.1）。这样做的好处是不会打断正在进行的 develop 分支的开发工作，能够让团队中负责 feature 开发的人与负责 hotfix 的人并行、独立的开展工作
• hotfix 分支只能从 master 上拉取，测试通过后合并回 master 分支和 develop 分支

之所以需要hotfix分支，是因为我们前面做了规定，master上不允许直接commit，master上的每一个commit都是来自其他分支的merge。

总结

这么看下来GitFlow还是不错的，毕竟他的应用场景比较全面，确实解决了开发时分支混乱的问题，而且为我们提供了代码分支管理的策略和思维。

但是它也并不是完美的，很多人诟病Gitflow太复杂。将这么一套复杂的流程应用到团队中，不仅需要每个人都能正确地理解和选择正确的分支进行工作，还对整个团队的纪律性提出了很高的要求。毕竟规则越复杂，应用起来就越难。很多团队可能不得不借助额外的帮助脚本去应用这一套复杂的规则。

像这种分支管理的规范只是万千分支管理策略中的一种，我们完全可以自己去对它进行修改和调整，找到适合自己团队的管理策略。

在找寻自己策略时有几点关键因素：

• 保证线上有个稳定的代码源（至关重要的一点）
• 不同团队保持并行开发，相互间的干扰度降至最低