Git分支模型策略

时间：2016-06-27 08:10:57

标签： git branching-and-merging git-flow branching-strategy

我们正在尝试遵循gitflow分支模型，但有一个转折。

我们有四个可以部署产品的服务器环境，每个服务器都有一个目的：开发，内部测试，外部测试和生产。

  • DevServer ，开发人员在开发时测试其不同功能。开发人员无法在他们的计算机上进行本地测试，他们必须在DevServer上进行更改以便能够进行测试
  • TestServer ，其中QA测试人员在开发人员完成后测试多个功能
  • ReleaseServer ，其中发布版在将其移至生产之前进行单独测试
  • 的生产服务器即可。生产服务器

我们正在努力使合并/冲突解决尽可能简单，因此我们创建了两个额外的分支，这些分支不是gitflow模型的一部分。

正常的gitflow分支

  • 的开发
  • master （匹配'ProductionServer'）
  • 的 featureXXX
  • releaseXXX （每周版本部署到“ReleaseServer”）

但这两个分支也不标准，可能需要改变......

  • dev-release （DevServer的副本）
  • 测试版 - （TestServer的副本）

然后过程如下：

  • 开发人员从'develop'
    • 创建'featureXXX'
  • 多个开发人员将他们不同的“功能”合并到“dev-release”分支中，并且“dev-release”分支被发布到“DevServer”，然后所有开发人员都可以测试他们的不同功能。并非所有这些功能都将出现在同一个下一个版本中
  • 一旦开发人员对上面的开发测试感到满意，他们就会将'featureXXX'合并到分支'test-release'中，并将其部署到'TestServer'。并非所有功能都属于同一个下一个版本。
  • 对featureXXX进行'TestServer'测试后，开发人员可以将他们的featureXXX关闭为'develop'。
  • 开发人员然后创建一个新的'releaseXXX'或将他们的'featureXXX'合并到现有的'releaseXXX'中。
  • 'releaseXXX'分支部署到'ReleaseServer'并进行测试。
  • 一旦'releaseXXX'测试签署，'releaseXXX'将合并到develop和master中，并部署到'ProductionServer'

我们是否搞砸了整个gitflow模型？

以下是我们的分店流程： enter image description here

2 个答案:

答案 0 :(得分：9)

要回答您的问题，请不要搞砸gitflow模型 - 更多地扩展它以满足您的需求。

通过将环境耦合到给定的分支，您可以在构建版本时为自己提供更大的灵活性。即假设您有两个非依赖功能（功能1和功能2）正在进行中，这两个功能已合并到您的“测试服务器”中。科。如果功能1测试失败，功能2仍然可以在没有功能1的情况下进一步发展 - 这是因为您合并到了测试服务器＆＃39;是一种单向合并 - 没有任何结果，没有历史。相反，您的功能2分支将合并到“开发”中。并最终＆＃39;掌握＆＃39;。

我们正在为自己采用/制定类似的策略。 我们的关键要求是容纳不可避免的樱桃选择功能。请注意，我们的解决方案虽然相当复杂，但它是为企业应用程序设计的，可作为多个业务所有者拥有的多个服务的平台，并利用多个内部框架。

环境

  • QA：让开发人员确保其功能可以测试。
  • 阶段：让项目经理/测试经理在各个业主的UAT测试之前进行抽烟测试
  • UAT：由业主＆＃39;进行全面测试和业务签收
  • BETA：仅仅是对部署/发布的测试
  • LIVE：..

这些环境分为两类，即“测试中”（QA，舞台和UAT）和“生产”。 （BETA和LIVE）。

分行

功能优先级可能经常发生变化，从测试问题到监管限制/请求。为了适应这种情况，创建了多个分支来表示环境/类别，如下所示：

  • Master：代表最后的生产版本
  • Release-Candidate：下一个制作版本
    • 的一系列功能
  • UAT：代表UAT环境
  • 阶段：代表QA＆＃39;和＆＃39;舞台＆＃39;
  • Feature-xxx：用于功能开发

我们还根据需要使用Master的HotFix分支，并在“预生产”中准备生产版本。分支（纠正错过的版本增量等 - 次要的东西）。

我们使用的分支机构图： A diagram of our Branches in use:

分支和合并/工作流程

  1. 我们始终从Release-Candidate分支新功能，因为此分支始终包含“承诺生产”和“＃39;特征。一旦做出生产承诺，任何事情都无法超越。

  2. 一旦功能准备好进行测试，它就会合并（单向）进入＆＃39; Stage＆＃39;。这会触发CI构建并部署到QA。

  3. 如果QA服务器看起来稳定，开发人员会触发自动部署到舞台。

  4. 如果需要更改，请在功能中进行更改并重复。如果可以进行业务测试，则从Feature合并到UAT。这部署到UAT。

  5. 如果功能未通过业务测试，则对功能进行更改并重复。如果功能延迟，则不采取任何措施。如果功能正常并签名，则合并到Release Candidate。

  6. 一旦收集（1个或多个）功能在Release-Candidate中，通过从Release-Candidate合并到Master（通过Pre-Production）来触发生产部署。

  7. 部署失败，然后是HotFix。如果没问题，请部署到Live。

    8. 我们使用TFS的工作流程如下所示：

    Our workflow, using TFS, looks like this:

    发布工作流程

    最后，对环境/类别的每个部署都将如下所示：

    Flow of deployment

答案 1 :(得分：0)

Git是一个版本控制系统。它维护源代码及其更改。开发在开发阶段停止。之后，源代码不应该改变。

当你将项目移动到下一个阶段（测试，发布，产品）时，你不应该提供源代码，而是从标记版本构建二进制文件，因为：

  • 源代码在不同环境中不会发生变化，
  • 两个版本可能会提供两个不同的二进制文件（对依赖项进行更改）
  • 维护不同版本将很困难。例如，
    • 项目的多个版本需要支持
      • 框架项目
      • A / B测试
      • ...
    • 修正错误。想象一下，当测试服务器上的新版本发布时，您需要从生产中进行修补。此修补程序需要通过相同的流程（测试，发布，生产）。因此，您需要使用错误修复覆盖测试分支，并在合并回新版本之后。这不是显而易见的，不是必要的，并且可能导致最初具有不同的代码。实际上，每次合并，在开发之后，源代码可能会有不同的风险。而且你可能需要在prod中解决合并冲突。

所以它可能不会干扰git-flow模型，但我认为这些点值得考虑。 实际上，我并不是git-flow策略的忠实粉丝。如果你有一分钟​​的时间给这些机会：

https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ https://trunkbaseddevelopment.com/

相关问题
最新问题