【Git 小妙招】来浅浅聊一下企业级开发模型

---

前言

本文是学习 Git 系列的最后一篇文章, 在学习完所有 Git 的使用技巧后, 本文重点来谈谈开发时的一些企业级开发模型.

关注收藏, 开始学习吧🧐

---

1. 讲个故事

我们知道，?个软件从零开始到最终交付，?概包括以下?个阶段：规划、编码、构建、测试、发布、部署和维护。

最初，程序?较简单，?作量不?，程序员?个?可以完成所有阶段的?作。但随着软件产业的?益发展壮?，软件的规模也在逐渐变得庞?。软件的复杂度不断攀升，?个?已经hold不住了，就开始出现了精细化分?。如下图所?：

但在传统的 IT 组织下，开发团队(Dev)和运维团队(Ops)之间诉求不同：

• 开发团队(尤其是敏捷团队)追求变化
• 运维团队追求稳定

双?往往存在利益的冲突。?如，精益和敏捷的团队把持续交付作为?标，?运维团队则为了线上的稳定?强调变更控制。部?墙由此建?起来,这当然不利于 IT 价值的最?化。

为了弥合开发和运维之间的鸿沟，需要在?化、?具和实践??的系列变??DevOps正式登上舞台。

DevOps（Development和Operations的组合词）是?种重视“软件开发?员（Dev）”和“IT运维技术?员（Ops）”之间沟通合作的?化、运动或惯例。透过?动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可?DevOps的强?。

讲了这么多，这个故事到底和我们系列的主题 Git 有什么关系呢？

举?个很简单的例?就能说明这个问题。?个软件的迭代，在我们开发?员看来，说?了就是对代码进?迭代，那么就需要对代码进?管理。如何管理我们的代码呢，那不就是 Git（分布式版本控制系统） ！所以 Git 对于我们开发?员来说其重要性就不??喻了。

2. 系统开发环境

?归正传，对于开发?员来说，在系统开发过程中最常?的?个环境必须要了解?下：

1. 开发环境：开发环境是程序猿们专??于?常开发的服务器。为了开发调试?便，?般打开全部错误报告和测试?具，是最基础的环境。
2. 测试环境：?个程序在测试环境?作不正常，那么肯定不能把它发布到?产机上。该环境是开发环境到?产环境的过渡环境。
3. 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测?设?的?套环境。其配置等基本和?产环境?致，?的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后?道防线，因为下?步你的项?就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的?些机器。
4. ?产环境：是指正式提供对外服务的线上环境，例如我们?前在移动端或PC端能访问到的APP都是?产环境。

这?个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。?张图总结：

对于规模稍微?点的公司来说，可不?这么?个环境，?如项?正式上线前还存在仿真/灰度环境，再?如还存在多套测试环境，以满?不同版本上线前测试的需要。

?个项?的开始从设计开始，??个项?的成功则从测试开始。?套良好的测试体系可以将系统中绝?部分的致命Bug 解决在系统上线之前。测试系统的完善和成熟也是衡量?个软件企业整体?平的重要指标之?，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产?直接的效益，但是它却是软件质量的最终保障，乃?项?能否成功的重要因素！

3. Git 分支设计规范

环境有了概念后，那么对于开发?员来说，?般会针对不同的环境来设计分?，例如：

分支	名称	适用环境
master	主分?	?产环境
release	预发布分?	预发布/测试环境
develop	开发分?	开发环境
feature	需求开发分?	本地
hotfix	紧急修复分?	本地

注：以上表格中的分?和环境的搭配仅是常?的?种，可视情况?定不同的策略。

3.1 master 分支

• master 为主分?，该分?为只读且唯?分?。?于部署到正式发布环境，?般由合并 release 分?得到。
• 主分?作为稳定的唯?代码库,任何情况下不允许直接在 master 分?上修改代码。
• 产品的功能全部实现后，最终在 master 分?对外发布，另外所有在 master 分?的推送应该打标签（tag）做记录，?便追溯。
• master 分?不可删除。

3.2 release 分支

• release 为预发布分?，基于本次上线所有的 feature 分?合并到 develop 分?之后，基于 develop 分?创建。可以部署到测试或预发布集群。
• 命名以 release/ 开头，建议的命名规则: release/version_publishtime 。
• release 分?主要?于提交给测试?员进?功能测试。发布提测阶段，会以 release 分?代码为基准进?提测。
• 如果在 release 分?测试出问题，需要回归验证 develop 分?看否存在此问题。
• release 分?属于临时分?，产品上线后可选删除。

3.3 develop 分支

• develop 为开发分?，基于 master 分?创建的只读且唯?分?，始终保持最新完成以及 bug 修复后的代码。可部署到开发环境对应集群。
• 可根据需求??程度确定是由 feature 分?合并，还是直接在上?开发（?常不建议）。

3.4 feature 分支

• feature 分?通常为新功能或新特性开发分?，以 develop 分?为基础创建 feature 分?。
• 命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。
• 新特性或新功能开发完成后，开发?员需合到 develop 分?。
• ?旦该需求发布上线，便将其删除。

3.5 hotfix 分支

• hotfix 分?为线上 bug 修复分?或叫补丁分?，主要?于对线上的版本进? bug 修复。当线上出现紧急问题需要?上修复时，需要基于 master 分?创建 hotfix 分?。
• 命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix 。
• 当问题修复完成后，需要合并到 master 分?和 develop 分?并推送远程。?旦修复上线，便将其删除。

?张图总结：

其实，以上跟?家谈的是企业级常?的?种 Git 分?设计规范：Git Flow 模型。但要说的是，该模型并不是适?于所有的团队、所有的环境和所有的?化。如果你采?了持续交付，你会想要?些能够尽可能简化交付过程的东西。有些?喜欢基于主?的开发模式，喜欢使?特性标志。然?，从测试的?度来看，这些反?会把他吓?跳。

关键在于站在你的团队或项?的?度思考：这种分?模型可以帮助你们解决哪些问题？它会带来哪些问题？这种模式为哪种开发提供更好的?持？你们想要?励这种?为吗？你选择的分?模型最终都是为了让?们更容易地进?软件协作开发。因此，分?模型需要考虑到使?者的需求，?不是盲?听信某些所谓的“成功的分?模型”。

所以对于不同公司，规范是会有些许差异，但万变不离其宗，是为了效率与稳定。

4. 修复问题建议

4.1 修复测试环境 Bug

在 develop 测试出现了 Bug，建议?家直接在 feature 分?上进?修复。

修复后的提测上线流程 与 新需求加?的流程?致。

4.2 修改预发布环境 Bug

在 release 测试出现了 Bug，?先要回归下 develop 分?是否同样存在这个问题。

• 如果存在，修复流程 与 修复测试环境 Bug流程?致。
• 如果不存在，这种可能性?较少，?部分是数据兼容问题，环境配置问题等。

4.3 修改正式环境 Bug

在 master 测试出现了 Bug，?先要看下 release 和 develop 分?是否同样存在这个问题。

• 如果存在，修复流程 与 修复测试环境 Bug 流程?致。
• 如果不存在，这种可能性也?较少，?部分是数据兼容问题，环境配置问题等。

4.4 紧急修复正式环境 Bug

需求在测试环节未测试出 Bug，上线运??段时候后出现了 Bug，需要紧急修复的。

有的企业?对紧急修复时，?持不进?测试环境的验证，但还是建议验证下预发布环境。

可基于 master 创建 hotfix/xxx 分?，修复完毕后发布到 master 验证，验证完毕后，将 master 代码合并到 develop 分?，同时删掉 hotfix/xxx 分?

拓展阅读
阿??流flow分?模型，及项?版本管理实践

---

总结

? 想了解更多知识, 请持续关注博主, 本人会不断更新学习记录, 跟随我一起不断学习 -> 跳转Git专栏.
? 感谢你们的耐心阅读, 博主本人也是一名学生, 也还有需要很多学习的东西. 写这篇文章是以本人所学内容为基础, 日后也会不断更新自己的学习记录, 我们一起努力进步, 变得优秀, 小小菜鸟, 也能有大大梦想, 关注我, 一起学习.

再次感谢你们的阅读, 你们的鼓励是我创作的最大动力!!!!!