Git 分支模型策略
Git branching model strategy
我们正在尝试遵循 gitflow 分支模型，但有所不同。
我们有四个可以部署产品的服务器环境，每个服务器都有一个用途：开发、内部测试、外部测试和生产。
- DevServer，开发人员在开发时测试他们不同的功能。开发人员无法在他们的机器上进行本地测试，他们必须在 DevServer 上进行更改才能进行测试
- TestServer，其中 QA 测试人员在开发人员完成后测试多个功能
- ReleaseServer，在将发布版本移至生产环境之前对其进行隔离测试
- ProductionServer。生产服务器
我们正在努力使合并/冲突解决尽可能简单，因此我们创建了两个不属于 gitflow 模型的额外分支。
正常的 gitflow 分支
- 发展
- master（匹配 'ProductionServer'）
- featureXXX
- releaseXXX（每周发布部署到 'ReleaseServer'）
还有这两个不标准的分支，可能需要更改...
- dev-release（DevServer 的副本）
- test-release（测试服务器的副本）
然后流程如下：
- 开发者从 'develop'
创建他们的 'featureXXX'
- 多个开发人员将他们不同的 'features' 合并到 'dev-release' 分支中，'dev-release' 分支被发布到 'DevServer'，然后所有开发人员都可以在那里测试他们的不同功能。并非所有这些功能都将出现在同一个下一个版本中
- 一旦开发人员对上面的开发测试感到满意，他们就会将他们的 'featureXXX' 合并到分支 'test-release' 中，并将其部署到 'TestServer'。并非此处的所有功能都将成为下一个版本的一部分。
- 在 'TestServer' 上完成对 featureXXX 的测试后，开发人员可以将其 featureXXX 关闭到 'develop'。
- 开发人员然后创建一个新的 'releaseXXX' 或将他们的 'featureXXX' 合并到现有的 'releaseXXX'。
- 'releaseXXX' 分支部署到 'ReleaseServer' 并测试。
- 一旦 'releaseXXX' 测试被签署，'releaseXXX' 被合并到 develop 和 master，并部署到 'ProductionServer'
我们是不是搞砸了整个 gitflow 模型？
这是我们的分支过程：
为了回答你的问题，不，你并没有搞乱 gitflow 模型——进一步扩展它以满足你的需要。
通过将环境耦合到给定的分支，您可以在构建版本时为自己提供更大的灵活性。也就是说，假设您有两个正在进行的非依赖特性（特性 1 和 2），它们都已合并到您的 'TestServer' 分支中。如果功能 1 未通过测试，功能 2 仍然可以在没有功能 1 的情况下进一步推进 - 这是因为您合并到 'TestServer' 是单向合并 - 没有任何结果，没有历史记录。相反，您的功能 2 分支合并到 'develop' 并最终合并到 'master'.
我们正在 adopting/developing 制定与您类似的策略。 我们的关键要求是适应不可避免的特征选择。请注意，尽管我们的解决方案相当复杂，但它是为企业应用程序设计的，作为由多个企业所有者拥有的多种服务的平台，并利用多个内部框架..
环境
- QA：供开发人员确保他们的功能是可测试的。
- 阶段：供项目经理/测试经理在 UAT 测试之前通过各种 'Business Owners'
进行冒烟测试
- UAT：由 'Business Owners'
进行全面测试和业务签署
- BETA：只是 deployment/release
的测试
- 直播：..
这些环境分为两类，'in-test'（QA、Stage 和 UAT）和 'production'（BETA 和 LIVE）。
分支机构
从测试问题到监管问题，功能优先级排序经常变化 restrictions/requests。为了适应这一点，创建了多个分支来表示 environment/categories，如下所示：
- Master：代表最后一个production release
- Release-Candidate：下一个 production release
的功能集合
- UAT：代表UAT环境
- 阶段：代表'QA'和'Stage'
- Feature-xxx：用于功能开发
我们还根据需要使用 Master 的 HotFix 分支，并在 'Pre-Production' 分支中准备生产版本（纠正遗漏的版本增量等 - 次要内容）。
我们使用中的分支图：
分支与合并/工作流
我们总是从 Release-Candidate 分支新功能，因为这个分支总是包含 'Committed for production' 功能。一旦做出生产承诺，就没有任何跳跃。
一旦一项功能准备好进行测试，它就会（单向）合并到 'Stage'。这会触发 CI 构建并部署到 QA。
如果 QA 服务器看起来稳定，开发人员会触发自动部署到 Stage。
如果需要更改，请在功能中进行更改并重复。如果可以进行业务测试，则从 Feature 合并到 UAT。这将部署到 UAT。
如果功能未通过业务测试，则更改功能并重复。如果功能延迟，则不采取任何措施。如果功能正常并已签署，则合并到发布候选版本。
一旦功能集合（1 个或多个）在发布候选版本中，通过从发布候选版本合并到主版本（通过预生产）触发生产部署。
部署失败，然后HotFix。如果可以，部署到 Live。
我们使用 TFS 的工作流程如下所示：
发布工作流程
最后，每个 environment/category 的部署看起来像这样：
Git是一个版本控制系统。它维护源代码及其更改。开发停止在开发阶段。在那之后，源代码应该不会改变。
当您将项目移至下一阶段（测试、发布、生产）时，您不应交付源代码，而应交付从标记版本构建的二进制文件，因为：
- 源代码在不同环境下没有变化，
- 两个构建可能提供两个不同的二进制文件（更改依赖项）
- 不同版本的维护会很困难。例如，
- 项目多版本需要支持
- 框架项目
- A/B 测试
- ...
- 错误修正。想象一下，当新版本在测试服务器上发布时，您需要从生产环境中进行修补程序。此修补程序需要经过相同的流程（测试、发布、生产）。所以你需要用错误修复覆盖测试分支，然后合并回新的发布版本。这不是显而易见的，也不是必需的，并且可能会导致最初打算使用不同的代码。实际上，对于每次合并，在开发之后，都存在源代码可能与预期不同的不必要风险。您可能需要解决产品中的合并冲突。
所以它可能不会干扰git-flow模型，但我认为这些点值得考虑。
实际上，我不是 git-flow 策略的忠实拥护者。如果你有时间给这些机会：
https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/
https://trunkbaseddevelopment.com/
我们正在尝试遵循 gitflow 分支模型，但有所不同。
我们有四个可以部署产品的服务器环境，每个服务器都有一个用途：开发、内部测试、外部测试和生产。
- DevServer，开发人员在开发时测试他们不同的功能。开发人员无法在他们的机器上进行本地测试，他们必须在 DevServer 上进行更改才能进行测试
- TestServer，其中 QA 测试人员在开发人员完成后测试多个功能
- ReleaseServer，在将发布版本移至生产环境之前对其进行隔离测试
- ProductionServer。生产服务器
我们正在努力使合并/冲突解决尽可能简单，因此我们创建了两个不属于 gitflow 模型的额外分支。
正常的 gitflow 分支
- 发展
- master（匹配 'ProductionServer'）
- featureXXX
- releaseXXX（每周发布部署到 'ReleaseServer'）
还有这两个不标准的分支，可能需要更改...
- dev-release（DevServer 的副本）
- test-release（测试服务器的副本）
然后流程如下：
- 开发者从 'develop' 创建他们的 'featureXXX'
- 多个开发人员将他们不同的 'features' 合并到 'dev-release' 分支中，'dev-release' 分支被发布到 'DevServer'，然后所有开发人员都可以在那里测试他们的不同功能。并非所有这些功能都将出现在同一个下一个版本中
- 一旦开发人员对上面的开发测试感到满意，他们就会将他们的 'featureXXX' 合并到分支 'test-release' 中，并将其部署到 'TestServer'。并非此处的所有功能都将成为下一个版本的一部分。
- 在 'TestServer' 上完成对 featureXXX 的测试后，开发人员可以将其 featureXXX 关闭到 'develop'。
- 开发人员然后创建一个新的 'releaseXXX' 或将他们的 'featureXXX' 合并到现有的 'releaseXXX'。
- 'releaseXXX' 分支部署到 'ReleaseServer' 并测试。
- 一旦 'releaseXXX' 测试被签署，'releaseXXX' 被合并到 develop 和 master，并部署到 'ProductionServer'
我们是不是搞砸了整个 gitflow 模型？
这是我们的分支过程：
为了回答你的问题，不，你并没有搞乱 gitflow 模型——进一步扩展它以满足你的需要。
通过将环境耦合到给定的分支，您可以在构建版本时为自己提供更大的灵活性。也就是说，假设您有两个正在进行的非依赖特性（特性 1 和 2），它们都已合并到您的 'TestServer' 分支中。如果功能 1 未通过测试，功能 2 仍然可以在没有功能 1 的情况下进一步推进 - 这是因为您合并到 'TestServer' 是单向合并 - 没有任何结果，没有历史记录。相反，您的功能 2 分支合并到 'develop' 并最终合并到 'master'.
我们正在 adopting/developing 制定与您类似的策略。 我们的关键要求是适应不可避免的特征选择。请注意，尽管我们的解决方案相当复杂，但它是为企业应用程序设计的，作为由多个企业所有者拥有的多种服务的平台，并利用多个内部框架..
环境
- QA：供开发人员确保他们的功能是可测试的。
- 阶段：供项目经理/测试经理在 UAT 测试之前通过各种 'Business Owners' 进行冒烟测试
- UAT：由 'Business Owners' 进行全面测试和业务签署
- BETA：只是 deployment/release 的测试
- 直播：..
这些环境分为两类，'in-test'（QA、Stage 和 UAT）和 'production'（BETA 和 LIVE）。
分支机构
从测试问题到监管问题，功能优先级排序经常变化 restrictions/requests。为了适应这一点，创建了多个分支来表示 environment/categories，如下所示：
- Master：代表最后一个production release
- Release-Candidate：下一个 production release 的功能集合
- UAT：代表UAT环境
- 阶段：代表'QA'和'Stage'
- Feature-xxx：用于功能开发
我们还根据需要使用 Master 的 HotFix 分支，并在 'Pre-Production' 分支中准备生产版本（纠正遗漏的版本增量等 - 次要内容）。
我们使用中的分支图：
分支与合并/工作流
我们总是从 Release-Candidate 分支新功能，因为这个分支总是包含 'Committed for production' 功能。一旦做出生产承诺，就没有任何跳跃。
一旦一项功能准备好进行测试，它就会（单向）合并到 'Stage'。这会触发 CI 构建并部署到 QA。
如果 QA 服务器看起来稳定，开发人员会触发自动部署到 Stage。
如果需要更改，请在功能中进行更改并重复。如果可以进行业务测试，则从 Feature 合并到 UAT。这将部署到 UAT。
如果功能未通过业务测试，则更改功能并重复。如果功能延迟，则不采取任何措施。如果功能正常并已签署，则合并到发布候选版本。
一旦功能集合（1 个或多个）在发布候选版本中，通过从发布候选版本合并到主版本（通过预生产）触发生产部署。
部署失败，然后HotFix。如果可以，部署到 Live。
我们使用 TFS 的工作流程如下所示：
发布工作流程
最后，每个 environment/category 的部署看起来像这样：
Git是一个版本控制系统。它维护源代码及其更改。开发停止在开发阶段。在那之后，源代码应该不会改变。
当您将项目移至下一阶段（测试、发布、生产）时，您不应交付源代码，而应交付从标记版本构建的二进制文件，因为：
- 源代码在不同环境下没有变化，
- 两个构建可能提供两个不同的二进制文件（更改依赖项）
- 不同版本的维护会很困难。例如，
- 项目多版本需要支持
- 框架项目
- A/B 测试
- ...
- 错误修正。想象一下，当新版本在测试服务器上发布时，您需要从生产环境中进行修补程序。此修补程序需要经过相同的流程（测试、发布、生产）。所以你需要用错误修复覆盖测试分支，然后合并回新的发布版本。这不是显而易见的，也不是必需的，并且可能会导致最初打算使用不同的代码。实际上，对于每次合并，在开发之后，都存在源代码可能与预期不同的不必要风险。您可能需要解决产品中的合并冲突。
- 项目多版本需要支持
所以它可能不会干扰git-flow模型，但我认为这些点值得考虑。 实际上，我不是 git-flow 策略的忠实拥护者。如果你有时间给这些机会：
https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ https://trunkbaseddevelopment.com/