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

​ 最初，程序比较简单，工作量不大，程序员一个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升，一个人已经 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 模型。但要说的是，该模型并不是适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付，你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式，喜欢使用特性标志。然而，从测试的角度来看，这些反而会把他吓一跳。

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

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