【Git】9. 开发模型 + 规范

企业级开发模型

讲个故事

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

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

但在传统的 IT 组织下，开发团队(Dev)和运维团队(Ops)之间诉求不同：
• 开发团队(尤其是敏捷团队)追求变化
• 运维团队追求稳定

双⽅往往存在利益的冲突。⽐如，精益和敏捷的团队把持续交付作为⽬标，⽽运维团队则为了线上的稳定⽽强调变更控制。部⻔墙由此建⽴起来,这当然不利于 IT 价值的最⼤化。
为了弥合开发和运维之间的鸿沟，需要在⽂化、⼯具和实践⽅⾯的系列变⾰⸺DevOps正式登上舞台。

DevOps（Development和Operations的组合词）是⼀种重视“软件开发⼈员（Dev）”和“IT运维技术⼈员（Ops）”之间沟通合作的⽂化、运动或惯例。透过⾃动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可⻅DevOps的强⼤。
讲了这么多，这个故事到底和我们课程的主题 Git 有什么关系呢？

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

系统开发环境

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

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

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

对于规模稍微⼤点的公司来说，可不⽌这么⼏个环境，⽐如项⽬正式上线前还存在仿真/灰度环境，再⽐如还存在多套测试环境，以满⾜不同版本上线前测试的需要。
⼀个项⽬的开始从设计开始，⽽⼀个项⽬的成功则从测试开始。⼀套良好的测试体系可以将系统中绝⼤部分的致命Bug 解决在系统上线之前。测试系统的完善和成熟也是衡量⼀个软件企业整体⽔平的重要指标之⼀，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产⽣直接的效益，但是它却是软件质量的最终保障，乃⾄项⽬能否成功的重要因素！

Git 分⽀设计规范

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

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

master 分⽀

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

release 分⽀

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

develop 分⽀

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

feature 分⽀

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

hotfix 分⽀

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

⼀张图总结：

其实，以上跟⼤家讲解的是企业级常⽤的⼀种 Git 分⽀设计规范：Git Flow 模型。但要说的是，该模型并不是适⽤于所有的团队、所有的环境和所有的⽂化。如果你采⽤了持续交付，你会想要⼀些能够尽可能简化交付过程的东西。有些⼈喜欢基于主⼲的开发模式，喜欢使⽤特性标志。然⽽，从测试的⻆度来看，这些反⽽会把他吓⼀跳。
关键在于站在你的团队或项⽬的⻆度思考：这种分⽀模型可以帮助你们解决哪些问题？它会带来哪些问题？这种模式为哪种开发提供更好的⽀持？你们想要⿎励这种⾏为吗？你选择的分⽀模型最终都是为了让⼈们更容易地进⾏软件协作开发。因此，分⽀模型需要考虑到使⽤者的需求，⽽不是盲⽬听信某些所谓的“成功的分⽀模型”。

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