所以我加入了一个最近（去年）从 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 分支策略存在一些问题，但认为它的简单性应该意味着几乎不会发生没有返回到 dev 的更改，并且仅提交历史不值得 git 的努力战略。
问题是，我对此没有回应。从根本上说，不是 100% 积极的代码要生产的想法是你在 dev 中测试的东西让我无休止......但我可以看到其他人可能会因为不合并而在 Hotfix 分支中忘记某些东西的风险更高它回到大师。另外，我喜欢 Git，虽然我不是专家，但 git 分支策略对我来说很有意义....然而，在几年前我自己从 TFS 过渡到 GIT 之后，我可以看到事情看起来多么复杂，而且那里在它成为每个人的第二天性之前会有很多错误。
我的问题是，是否有更令人信服的理由使用获取分支策略？我已经搜索了很多“樱桃采摘分支策略”和其他变体，但没有提出任何建议，所以我希望我在这里遗漏了一些重要的东西。