所以我加入了一个团队，最近（去年）从TFS搬到了GIT。分支策略就是这样。 Dev - ＆gt;发布 - ＆gt;主。当Dev准备就绪时，合并到Release。从发布构建并部署到各种环境。一旦到达第一个生产环境，就合并到Master，因此master始终是保留的生产状态。如果需要修补程序，请在Dev，Cherry-pick to Release中进行更改，一旦部署到prod，cherry-pick to master。永远不要从Master转发到Release或Release to Dev，总是将代码向一个方向流动....如果我们确实需要向后合并，那么它是另一个樱桃选择（如果你能找到它）或者是一个巨大的合并冲突。
优点：
缺点：
所以，这是一个非常TFS集中的做事方式，我正在推动一个双分支系统。开发和硕士。当我们准备好发布时，将Master合并回Dev以确保一切都是同步的，然后Dev to Master标记提交以便在需要时进行简单参考。如果是修补程序，则从master分支，根据需要进行修复，根据需要进行部署并合并回master。如果在Dev中需要，则将Master合并回dev，或者等待下一个版本。
优点：
缺点：
所以，团队中的另一位开发人员同意Cherry-pick分支策略有一些问题，但认为它的简单性应该意味着不能让它回到开发阶段的变化几乎不会发生，并且单独提交历史记录是不值得的git策略。
问题是，我对此没有回应。从根本上说，没有100％肯定代码的想法就是你在开发中测试的东西让我感到震惊...但是我可以看到其他人如何可能会因为不合并而忘记Hotfix分支中的某些东西的风险更大它回到了师父。另外，我喜欢Git，虽然我不是专家，但是git分支策略对我来说很有意义....但是，自己多年前从TFS过渡到GIT后，我可以看到复杂的东西看起来有多么复杂在它成为每个人的第二天性之前会有很多错误。
我的问题是，是否有更令人信服的理由使用get分支策略？我已经搜索了很多关于“Cherry Picking分支策略”和其他变种的内容并没有提出任何建议，所以我希望我在这里缺少一些重要的东西。
答案 0 :(得分：0)
也许不是解决方案，而是一些建议：
跟踪修复，这样做更有效率进行合并而不是分享。您可以更好地了解查看图表的历史记录。而且，更重要的是，对于给定的提交/修复，您可以轻松地看到哪些分支包含它。
你应该在分支中修复，因为移动越少，哪个更像生产提交。所以你应该创建一个分支来从'release'分支进行修复（并将它合并到'release'和'dev'）或直接修复'release'并合并'dev'。因为如果你在'dev'中进行开发，自“release”发布以来可能会发生很大变化，你可能会遇到引入bug的合并冲突。
当你做樱桃挑选时，很难找到每个提交是否在2个分支中。这可能适用于1或2次提交但在所有情况下都不可行。通过合并，您可以确保所有提交都已报告给'dev'分支。
您可以在此博客文章中找到更多解释git flow的解释： http://nvie.com/posts/a-successful-git-branching-model/