logo标签列表

Git分支模型策略

gitbranching-and-merginggit-flowbranching-strategy
9
我们正在尝试遵循gitflow分支模型，但有所改变。
我们有四个服务器环境，产品可以部署到每个服务器上，每个服务器都有自己的用途：开发、内部测试、外部测试和生产。
  • DevServer，开发人员在开发时测试其不同的功能。开发人员无法在本地计算机上进行测试，他们必须在DevServer上进行更改才能进行测试
  • TestServer，QA测试人员在开发人员完成后测试多个功能
  • ReleaseServer，在将发布内容移至生产之前，对发布内容进行隔离测试
  • ProductionServer。生产服务器
我们试图使合并/冲突解决尽可能简单，因此我们创建了两个额外的分支，这不是gitflow模型的一部分。
普通的gitflow分支
  • develop（开发分支）
  • master（主分支，与“ProductionServer”匹配）
  • featureXXX（功能分支）
  • releaseXXX（每周发布的版本部署到“ReleaseServer”）

但还有这两个不符合标准的分支可能需要更改...

  • dev-release（DevServer的副本）
  • test-release（TestServer的副本）

然后按照以下步骤进行：

  • 开发人员从“develop”创建他们的“featureXXX”
  • 多个开发人员将其不同的“features”合并到“dev-release”分支中，“dev-release”分支发布到“DevServer”，所有开发人员可以在此测试其不同的功能。并非所有这些功能都将包含在同一下一个版本中。
  • 一旦开发人员对上述开发测试满意，他们将他们的“featureXXX”合并到“test-release”分支中，并将其部署到“TestServer”。这里的不是所有功能都将成为同一下一个版本的一部分。
  • 一旦在“TestServer”上对featureXXX进行了测试，开发人员就可以将其关闭到“develop”中。
  • 然后，开发人员可以创建新的“releaseXXX”或将其“featureXXX”合并到现有的“releaseXXX”中。
  • “releaseXXX”分支被部署到“ReleaseServer”并进行测试。
  • 一旦“releaseXXX”测试得到批准，“releaseXXX”就会合并到develop和master中，并部署到“ProductionServer”

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

这是我们的分支流程： 在此输入图片描述
这个问题与以下相关，并且有相关的答案：https://dev59.com/Aozda4cB1Zd3GeqPsOBY#59369220 - David Smit
2个回答
13
回答你的问题，不，你没有搞砸gitflow模型，而是扩展了它以满足你的需求。
通过将环境与给定分支耦合，您在构建发布时具有更多灵活性。例如，假设您正在进行两个不相关的功能（功能1和2），这两个功能都已合并到您的“TestServer”分支中。如果功能1在测试中失败，则功能2仍然可以继续进行而不需要功能1-这是因为您合并到“TestServer”的是单向合并-没有任何历史记录出现。相反，您的Feature 2分支将合并到“develop”，最终合并到“master”。
我们正在采用/开发类似于您的策略。对我们来说，关键要求是适应无法避免的功能挑选。请注意，我们的解决方案虽然相当复杂，但是设计为企业应用程序，作为由多个业务所有者拥有和使用多个内部框架的多个服务的平台。
环境
  • QA：供开发人员确保其功能可测试。
  • Stage：供项目经理/测试经理在各个“业务所有者”进行UAT测试之前进行冒烟测试。
  • UAT：供“业务所有者”进行完整测试和业务签署。
  • BETA：仅用于部署/发布的测试。
  • LIVE：..

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

分支

由于功能优先级可能经常变化，从测试问题到监管限制/请求。为了适应这一点，创建多个分支以表示以下环境/类别：

  • Master：代表最后一个生产版本
  • Release-Candidate：下一个生产版本的特性集合
  • UAT：代表UAT环境
  • Stage：代表“QA”和“Stage”
  • Feature-xxx：用于功能开发

我们还根据需要从Master创建HotFix分支，并在“Pre-Production”分支中准备生产发布（纠正遗漏的版本增量等-小事情）。

我们使用的分支图示：

我们使用的分支图示：

分支和合并/工作流程

我们总是从Release-Candidate分支中创建新的功能，因为该分支始终包含“已提交生产”的功能。一旦已经做出生产承诺，就不会有任何跳跃。
一旦功能准备好进行测试，就会将其（单向）合并到“Stage”中。这会触发CI构建并部署到QA。
如果QA服务器看起来稳定，开发人员会触发自动部署到Stage。
如果需要更改，则在功能中进行更改并重复上述步骤。如果对业务测试OK，则从Feature合并到UAT。这将部署到UAT。
如果功能未通过业务测试，则在功能中进行更改并重复上述步骤。如果功能延迟，则不采取任何行动。如果功能OK并获得签名，则合并到Release Candidate。
一旦功能集（1个或多个）位于Release-Candidate中，请通过从Release-Candidate到Master（通过Pre-Production）合并来触发生产部署。
如果部署失败，则进行热修复。如果OK，则部署到Live。
我们使用TFS的工作流程如下：

Our workflow, using TFS, looks like this:

发布工作流

最后，每次部署到一个环境/类别看起来都像这样：

Flow of deployment

1
哇，我真的非常感谢你提供深入的答案和解释！！我没有像你这样记录我们的过程，看到图表真的很有帮助。我将把你的回答标记为最佳答案，因为现在我知道创建单向分支是可以的（用于测试长期和短期运行的功能），只有在经过签署后才将功能合并到发布中。（尽管我将保持我们的策略不变，并很快在这里发布它） - David Smit
0

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

当您将项目移动到下一个阶段（测试、发布、生产）时，您不应该交付源代码，而应该交付从已标记版本构建的二进制文件，因为：

  • 源代码在不同环境中不会改变，
  • 两个构建可能提供两个不同的二进制文件（依赖关系的更改），
  • 不同版本的维护将很困难。例如，
    • 需要支持多个版本的项目
      • 框架项目
      • A/B测试
      • ...
    • 修复错误。想象一下，当测试服务器上有新版本时，您需要从生产环境进行热修复。这个热修复需要通过相同的流程（测试、发布、生产）进行。因此，您需要用bugfix覆盖测试分支，并在合并回新版本后再次合并。这不明显，也不必要，可能导致最初意图的不同代码。实际上，在每次开发后合并时，存在不必要的风险，源代码可能与原本意图的不同。您可能需要在生产环境中解决合并冲突。

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

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

无论如何，团队在提交/推送给其他人（或机器人）之前，在他们的开发工作站上执行完整的“预集成”构建（编译、单元测试、集成测试）。我认为这个声明需要一些假设：1）产品可以以二进制形式打包，不需要分布式依赖项或持久化数据/服务2）单元/集成测试是全面的100%，不需要手动检查。 - Khoa
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接