标签：依据 多版本 理想 release ref 接受 出现 other 灰度
本以为使用 Git 的工作流规范依据很普遍了，发现事实并不是那样。找了些资料，结合实际的工作情况，尝试整理出一个规范。
Git 工作流是一个如何使用 Git 以一致和高效的方式来完成工作的建议。在 Git 管理的项目中与团队合作时，确保团队对如何应用工作流达成一致意见是很重要的。在看下面介绍的内容时，请记住，这些工作流是一个指导原则，而不是具体的规则。可以根据自身实际情况进行相应调整。
当评估团队工作流时，考虑团队的文化是很重要的一件事。你希望工作流提高团队的效率，而不是成为限制生产力的负担。当评估时可以考虑的事情：
下面就来比较一下常见的 Git 工作流。
详细介绍见 Git branching model 。
优点：
缺点：
详细介绍见 GitHub flow 。
优点：
feature 分支和 master ，发布到线上更加简化。feature 上持续进行，减少了一些合并提交的开销。缺点：
feature 合并到 master 之前， feature 分支需要发布到一个线上环境验证，也就是说可能同时存在多个线上环境，这可能需要额外的开销。master 时相互之间出现冲突可能性更高。详细介绍见 GitLab Flow 。
优点：
issue 跟踪的方式，减轻了项目管理上的工作，让每一个开发人员能够有意识自我管理。缺点：
根据上面的几种工作流，以及个人在实际工作中碰到的情况，对于规范有下面的一些想法。
下面以环境功能作为一个切入点开始。
一般有开发环境、测试环境、生产环境，下面说下每个环境的特点。
主要用于开发，例如接口调试。这个环境中的代码变化最为频繁。可能有以下的形式：
主要用于测试，这个环境中代码相对稳定，一般都是有单独的服务器部署。测试和开发会出现并行的情况，因此未正常运行的代码通常不允许进入到这个环境中，以免影响测试。测试的类型可能有：
用于线上对外访问，这个时候就是真实用户的环境。只有特定的人员会有相关代码访问权限。
整体上跟 Git 工作流中分支策略差不多。原则是每一个分支对应一个特定环境。
feature 分支，名称统一前缀 feature/。开发完成后，经过确认会进行发布的 feature ，才能合并到此分支。合并后删除 feature 分支。待确认 develop 分支运行正常后，就可以合并到 release 分支，或者创建基于 develop 的 release 分支。进入到测试环节。
develop 分支。相关测试通过后，开始合并到 master 分支，同时合并到 develop 分支，因为期间可能有 bug 修复。接着进入到发布环节。
tag 。merge 指令强制使用 --no-ff 参数，产生对应合并记录，方便回溯。develop 和 release 分支一般开发人员有合并权限， master 分支合并权限特定人员才能有。按照上面分支对应的环境，对 bug 进行区分。
release 分支创建修复分支，名称统一前缀 bugfix/ 。release 分支。master 之前， release 合并到 master 之后就删除该分支。master 分支创建修复分支，名称统一前缀 hotfix/ 。release 分支，在测试环境进行验证，验证通过后，将此分支分别合并到 master 和 develop 。上面所说是一个正常的流程，但实际中不会那么理想。可能出现下面的情况。
release 对应测试环境是一个版本，由于时间问题，提前开发的功能分支 feature/function 已完成，需要马上进行测试。
这个时候，可以直接基于 feature/function 分支构建一个单独的测试环境。这个需要在持续构建系统里面花费一定成本。待 release 发布后，按照原有的流程合并即可。
一般测试环境和生产环境的数据和配置是相互独立的，有些时候生产的问题无法在测试环境复现，那么处理的方式有：
灰度发布的情况，生产上有两套环境，不同的用户在不同的环境。这个时候，可以这么做：
master 创建一个预发布的分支。release 合并到预发布分支中，灰度过后，将预发布分支合并到 master 。master 和 develop 。以上遵循一个分支对应一个环境的原则，也可以一个分支对应多个环境。例如 develop 分支，构建后，可以部署到两个不同服务器，测试人员在一个环境中使用，开发人员在另外一个环境中使用，也是相互不影响的。这个需要在持续构建工具里面进行相关的配置。
按照上面的流程，可以发现，分支一旦增加，就少不了创建、合并的操作。有些时候团队开发也就 2、3 个人。那么在这个时候，可以简化的步骤有：
feature 分支，直接在 develop 上开发。release 上修改。master 。在下个版本合并到 release 之前，统一把 master 合并到 develop 一次。随着团队规模的扩张，更加详细的规则变的愈加必要。强化的步骤有：
issue 开始，描述开发的内容和实现方式，并给相关人员审阅。随后的进度状态都在这个 issue 中反映。标签：依据 多版本 理想 release ref 接受 出现 other 灰度
原文地址：https://www.cnblogs.com/thyshare/p/12530824.html
