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