Git Cherry pick分支策略？

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

优点：

• 简单的

缺点：

• 提交历史在分支之间是无用的，因为它们不匹配
• 意外地直接对Release或Master和no Dev所做的更改将永远不会返回到Dev，直到有人在错误被重写后再次注意到错误，或者合并冲突警告有人（不太可能，因为这是一种盲目的合并，人们将被训练忽略合并冲突）

因此，这是一种非常TFS集中的做事方式，我正在推动两个分支系统。德夫和主人。当我们准备发布时，将Master合并回Dev以确保所有内容都同步，然后Dev-to-Master标记提交，以便在需要时方便参考。在出现热修复程序的情况下，从主程序分支，根据需要进行修复，根据需要进行部署，然后合并回主程序。如果在Dev中需要，那么将Master合并回Dev，或者等待下一个版本

优点：

• 只有当有人从HF分支部署并忘记将其合并回发布时，提交才会丢失（我认为只有从主分支部署到prod才能强制合并…但是构建需要很长时间，所以这是一个关键点…）
• 提交历史记录将在分支之间匹配，这样您就知道事情是同步的
• 合并冲突应该由做出更改的人员大大减少和/或处理，以便他们更好地了解如何处理冲突

缺点：

• 更复杂，特别是如果你来自TFS。。。我以前去过那里
• 如果同时进行多个修补程序，这可能会变得混乱

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

问题是，我对此没有回应。从根本上说，你在dev中测试的代码不是100%正确的，这让我非常恼火。。。但我可以看到，其他人可能会因为没有将热修复程序分支合并回主程序而忘记热修复程序分支中的某些内容，尤其是在更高的风险下。另外，我喜欢Git，虽然我不是专家，但Git分支策略对我来说很有意义。。。。然而，几年前我自己就已经从TFS过渡到GIT了，我可以看到事情看起来是多么复杂，在它成为每个人的第二天性之前会有很多错误

---

我的问题是，是否有更令人信服的理由使用get分支策略？我已经搜索了很多“樱桃采摘分支策略”和其他变体，但还没有找到任何建议，所以我希望我在这里遗漏了一些主要内容。

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

• 为了跟踪修复，合并比挑选樱桃要有效得多。你可以通过图表更好地了解历史。更重要的是，对于给定的提交/修复，您可以很容易地看到哪些分支包含它

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

当您进行樱桃采摘时，很难发现每个提交是否在2个分支中。这可能适用于1或2次提交，但并非在所有情况下都可行。对于合并，您可以确保所有提交都已报告给“dev”分支

您可能会在这篇解释git流的博文中找到更多解释：

---

是不是否决票可以解释其投票，因为这些建议是我们在我的项目中真正有经验的建议？TFS有两种风险投资：Git和TFVC，所以你的意思是从TFS转移到Git就是从TFVC转移到Git？还有一些分支策略（模型），但没有任何“樱桃树分支策略”。此外，您可以在这里引用一个成功的分支模型。