Git Cherry-pick 分支策略？

Question

所以我加入了一个最近（去年）从 TFS 迁移到 GIT 的团队。分支策略是这样的。开发 -> 发布 -> 主控。 Dev 准备好后，合并到 Release。从 Release 构建并部署到各种环境。一旦它到达第一个生产环境，就合并到 Master，因此 master 始终是一个保留的生产状态。如果需要修补程序，请在 Dev 中进行更改，Cherry-pick 到 Release，一旦部署到 prod，cherry-pick 到 master。永远不要从 Master 向后合并到 Release 或 Release 到 Dev，始终将代码流向一个方向......如果我们确实需要向后合并，它要么是另一个樱桃选择（如果你能找到它），要么是与大量的巨大合并冲突。

优点：

• 简单

缺点：

• 提交历史记录在分支之间是无用的，因为它们不会匹配。
• 意外直接对 Release 或 Master 而不是 Dev 进行的更改，永远不会回到 Dev，直到有人在覆盖后再次注意到错误或合并冲突提醒某人（不太可能，因为这主要是盲目的合并和人们将接受培训以忽略合并冲突。）

所以，这是一种非常 TFS 集中的做事方式，我正在推动一个两分支系统。开发者和大师。当我们准备好发布时，将 Master 合并回 Dev 以确保一切同步，然后 Dev 到 Master 标记提交以便在需要时参考。如果出现修补程序，则从 master 分支，根据需要进行修复，根据需要进行部署并合并回 master。如果在 Dev 中需要，则将 Master 合并回 dev，或者等待下一个版本。

优点：

• 只有在有人从 HF 分支部署并忘记合并回 Release 时，提交才会丢失（我认为仅从 Master 部署到 prod 以强制合并...但是构建需要很长时间，所以这是一个症结... )
• 提交历史记录将在分支之间匹配，因此您知道事情是同步的
• 合并冲突应该被大大减少和/或由进行更改的人处理，以便他们更好地知道如何处理它们。

缺点：

• 更复杂，尤其是如果您来自 TFS...我以前去过那里
• 如果同时进行多个修补程序，这可能会变得一团糟。

因此，团队中的另一位开发人员同意 Cherry-pick 分支策略存在一些问题，但认为它的简单性应该意味着几乎永远不会发生未返回到开发的更改，并且仅提交历史记录不值得付出努力git 策略。

问题是，我对此没有回应。从根本上说，不是 100% 积极的代码要生产的想法是你在 dev 中测试的东西让我无休止......但我可以看到其他人可能会因为不合并而在 Hotfix 分支中忘记某些东西的风险更高它回到大师。另外，我喜欢 Git，虽然我不是专家，但 git 分支策略对我来说很有意义....然而，几年前我自己从 TFS 过渡到 GIT，我可以看到事情看起来多么复杂，而且那里在它成为每个人的第二天性之前会有很多错误。

我的问题是，是否有更令人信服的理由来使用获取分支策略？我已经搜索了很多“樱桃采摘分支策略”和其他变体，但没有提出任何建议，所以我希望我在这里遗漏了一些重要的东西。

Answer 1

也许不是解决方案，而是一些建议：

• 要跟踪修复，进行合并比挑选要高效得多。您可以更好地了解查看图表的历史记录。而且，更重要的是，对于给定的提交/修复，您可以轻松查看哪些分支包含它。

• 您应该修复移动越少且更像生产提交的分支。因此，您应该创建一个分支以从“发布”分支进行修复（并将其合并到“发布”和“开发”中）或直接修复“发布”并合并到“开发”中。因为如果您在“开发”中进行开发，自“发布”完成后可能会发生很大变化，您可能会遇到合并冲突，从而有引入错误的风险。

当您进行挑选时，很难确定每个提交是否在 2 个分支中。这可能适用于 1 或 2 次提交，但并非在所有情况下都可行。通过合并，您可以确定所有提交都已报告给“开发”分支。

您或许可以在这篇解释 git 流程的博文中找到更多解释： http://nvie.com/posts/a-successful-git-branching-model/