我在this帖子中回答了同样的问题，我接受了答案，但我没有看到明确的最佳做法。因此，假设链接的答案仍然有效（即＆＃34;手动执行＆＃34;），我将再次询问问题是什么是最佳实践＆＃34;在浓密的树上手动分配单个更改（即许多需要更新的分支）。我想，当你有无法访问的遥控器时，这是一个更严重的问题。
例如，配置文件在项目的根目录中设置错误。现在有人发现整个项目中的一致问题是此配置设置。所以，他们修复它并合并它......啊......在哪里......怎么样？有30个分支机构，他可以访问和其他遥控器，他没有？当你挑选合并提交时，你是否与所有分支列表坐了半个小时并逐个交叉它们？发送电子邮件到遥控器？我没有看到好的做法可以效仿。
现在，我一直在零碎地做，但我一直在检查分支，忘记他们还没有更新，突然被这个该死的设置咬了......一次又一次！我对Vagrantfile的更改也遇到了这个问题。基本上任何影响所有分支的代码都变得非常缺乏弹性。
我是git的新手所以也许我也忽略了一些简单的练习。例如，除了通常的主/开发布局之外，我正在考虑在项目上放置一个分支。像主/开发/基础设施的东西。它并没有缓解这个问题，但至少你不必每次在基础架构发生变化时都选择添加到每个分支的提交，你可以直接拉入整个基础架构分支。
答案 0 :(得分：3)
如果这是你的问题 - 你正在使用git错误（尽管项目效率不高，或者你的效率不高，无论如何）。几乎所有例外的“最佳实践”git流都有一个发布分支，所有其他分支都来自。例如，如果您有一个主分支和一个开发分支，并且所有其他分支都基于开发分支。比所有分支机构都应该努力融入开发分支。因此，如果您需要快速修复生产，那么您可以在一个全新的分支中快速修复，而不是将其合并到开发中，而不是在master中合并开发。现在发布版本已经修复 - 剩下的分支仍然可以处理。
换句话说，如果每个分支真正修复和测试代码的小部分（即分布式），它们不需要来自其他分支的修复，每个分支应该处理相互排斥的问题，因此它们总是可以独立合并，没有冲突。否则，您没有真正使用分布式工作流，并且您可能应该使用不同的源代码管理器。