Chef 从之前的 git 分支发布了一本食谱答案

【问题标题】：Chef release a cookbook from previous git branchChef 从之前的 git 分支发布了一本食谱
【发布时间】：2015-11-16 21:29:34
【问题描述】：

我部署了多本 CHEF 食谱。每个都根据语义版本进行版本控制。

我的生产环境正在使用说明书 0.1.1
我的舞台环境正在使用cookbook 0.2.0

2.0 版有很大的变化，我还不能部署到生产环境中。发现一个需要在 0.1.x 中修复的错误。我如何创建说明书 0.1.2 并将其部署到生产环境，而不将说明书 2.0 的重大变化合并到生产环境中？

使用 git-flow。新版本是从开发分支创建的。然后合并回开发和测试。测试后合并到master，给定一个git标签并自动部署到chef服务器。

    0.1.1              0.2.0
   /      \           /      \
o-o--------o-o---X---o--------o-o-------- develop
 \            \                  \
  o------------o------------------o------ master

当食谱被发布时，发布分支被删除。

我假设我需要结帐X，然后创建食谱 0.1.2。但是，当我尝试将说明书 0.1.2 合并到开发分支时，我发现 metadata.rb 和 CHANGELOG.md 存在合并冲突 (Y)。虽然我可以在 0.2.0 食谱发布之前重新设置基准，但这会改变我的整个历史。

                         _________________
                        /                 \
     0.1.1         0.1.2     0.2.0         \
   /      \       /         /      \        \
o-o--------o-o---X---------o--------o-o------Y-- develop
 \            \                        \
  o------------o------------------------o------- master

部署旧说明书的最佳方式是什么？

我知道关于反向移植 git 提交的类似问题已在 SO 上提出，但没有一个涉及如何处理不可避免的合并冲突。我是否应该接受会有冲突并手动解决它们？

更新

为了澄清，我已经有了一个策略，在不同的环境中使用不同的食谱，使用一个 environment.json 文件和version pinning。

【问题讨论】：

标签： git merge chef-infra git-flow

【解决方案1】：

所以这里有两个不相关的问题：

首先是如何在 git-flow 下管理维护分支。我不喜欢他们的结构，但我认为最正式的方法是从现有标记创建一个新分支，进行更改，标记维护版本，然后将该分支合并到 master。

其次，是如何在 Chef 中进行发布管理。通常这是在 Chef 环境中完成的。每个环境都可以有一组关于该环境中允许每个说明书的哪些版本的约束。您可以将生产限制设置为~> 0.1.0，因此允许维护版本，但不允许新的次要版本。也就是说，为了与 SemVer（和相关）保持一致，您应该使用主要版本来指示兼容中断。

【讨论】：

对 git-flow 的了解有限，但有support branches 的概念。但它似乎没有被广泛理解。
git "support branches" 确实完美地描述了我的问题。由于厨师食谱是使用 jenkins 从主分支自动部署的，因此支持分支似乎需要合并到主分支中（有冲突）。除非我想手动上传食谱。

【解决方案2】：

@StephenKing 建议的 Git 流 "support branches" 是 git 问题的答案，也是厨师部署问题的部分解决方案。

我最终做了什么：

创建一个名为“support/1.0”的新 git 分支

将我的修补程序应用到该分支，然后将 metadata.rb 和 CHANGELOG.md 更改为 v0.1.2 并添加一个 git 标签。

然后我将该分支合并到 master 中，跳过了 develop (Z)。 metadata.rb 和 CHANGELOG.md 有我手动解决的冲突。然后 Jenkins 将 0.1.2 食谱上传到厨师服务器。

删除“support/1.0”分支。

                       v0.1.2_________________
                      /                       \
     0.1.1       support/1.0      0.2.0        \
   /      \     /                /     \        \
o-o--------o---X----------------o-------o--------\-- develop
 \          \                            \        \
  o----------o----------------------------o--------Z- master

优点这种方法：

不长生支援分会
在带有 git 标签的版本控制中仍有说明书
不必重新设置历史记录

缺点

主分支将继续显示旧版本，直到下一个版本

开发 metadata.rb = "0.2.0"
主元数据.rb = "0.1.2"

当版本 0.2.1 发布时，两个分支中的 metadata.rb 将显示正确的最新版本。在此之前，这可能会让人们误以为 0.1.2 是最新的食谱。

【讨论】：