厨师从以前的git分支发布了一本食谱

我部署了多本厨师烹饪书。每个版本都根据语义版本控制进行版本控制

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

版本2.0有一个很大的变化，我还不能部署到生产环境中。发现一个bug，需要在0.1.x中进行热修复。我如何创建Cookbook0.1.2并将其部署到生产环境中，而不将Cookbook2.0的巨大变化合并到生产环境中

使用git流。新版本是在develope分支之外创建的。然后重新合并到开发和测试中。测试完成后，它会被合并到master，给出一个git标记并自动部署到chef服务器

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

发布cookbook时，将删除发布分支

我假设我需要签出

X

，然后创建Cookbook0.1.2。然而，当我尝试将cookbook 0.1.2合并到develop分支中时，我发现

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提交的后移植，但是没有一个涉及到如何处理不可避免的合并冲突。我是否应该接受会有冲突并用手解决它们

更新

---

为了澄清这一点，我已经有了一个策略，可以在不同的环境中使用environments.json文件和

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

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

---

第二，如何在Chef中进行发布管理。通常，这是通过Chef环境完成的。每个环境都可以有一组关于该环境中允许哪些版本的烹饪书的约束。您可以将生产约束设置为

~>0.1.0

，这样就允许维护版本，但不允许新的次要版本。也就是说，为了与SemVer（及相关）保持一致，您应该使用主要版本来表示compat中断。

因此这里有两个不相关的问题：

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

第二，如何在Chef中进行发布管理。通常，这是通过Chef环境完成的。每个环境都可以有一组关于该环境中允许哪些版本的烹饪书的约束。您可以将生产约束设置为

~>0.1.0

，这样就允许维护版本，但不允许新的次要版本。也就是说，为了与SemVer（及相关版本）保持一致，您应该使用主要版本来指示compat中断。

Git flow“@StephenKing建议的”是Git问题的答案，也是chef部署问题解决方案的一部分

我最终做了什么：

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

将我的修补程序应用于该分支，然后将metadata.rb和CHANGELOG.md更改为

v0.1.2

，并添加git标记

然后我将该分支合并到master中，跳过develope（Z）。meatadata.rb和CHANGELOG.md有冲突，我手动解决了这些冲突。Jenkins随后将0.1.2食谱上传到chef服务器

删除“支持/1.0”分支

此方法的优点：

• 无长期生活支助处
• 在带有git标记的版本控制中仍然有cookbook
• 不必重新确定历史的基础

缺点

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

开发元数据。rb=“0.2.0”
Master metadata.rb=“0.1.2”

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

Git-flow“@StephenKing建议的”是Git问题的答案，也是chef部署问题解决方案的一部分

我最终做了什么：

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

将我的修补程序应用于该分支，然后将metadata.rb和CHANGELOG.md更改为

v0.1.2

，并添加git标记

然后我将该分支合并到master中，跳过develope（Z）。meatadata.rb和CHANGELOG.md有冲突，我手动解决了这些冲突。Jenkins随后将0.1.2食谱上传到chef服务器

删除“支持/1.0”分支

此方法的优点：

• 无长期生活支助处
• 在带有git标记的版本控制中仍然有cookbook
• 不必重新确定历史的基础

缺点

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

开发元数据。rb=“0.2.0”
Master metadata.rb=“0.1.2”

---

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

对git flow的了解有限，但有一个概念。但它似乎没有被广泛理解。git的“支持分支”确实完美地描述了我的问题。由于chef cookbooks是与jenkins一起从主分支自动部署的，因此支持分支似乎需要合并到主分支中（存在冲突）。除非我想手动上传t

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