git: merge 一个经常更新的远程分支？

Question

只是想知道 merge 回 master 的通常做法是什么，当 HEAD 很可能在 merge 前的最后一次 pull 后再次更新时。为了说明，在下图中，M 是预期的 merge 点，但是由于在提交 M 并准备好推送时主 HEAD 已更新为 A1，因此 M1 将成为新的预期 merge 点，换句话说，一个新的 merge 点必须尝试。

master-----A----A1---...
            \     \
             M     M1
            /     /
local------B------

请注意，我宁愿不 merge M 和 A1，因为可能还有 A2、A3，如果问题再次出现，它看起来太乱了，还有额外的意外 merge 。如果 local 中的更改充分独立于 master 中的更改，有时我会在 master 之上重新设置基础，我发现这是一个更简单的解决方案。但在其他时候，我真的希望有一些方法可以“重新使用”我为 M、M1 所做的 merge 工作。

Answer 1

假设团队中的每个人都维护着自己的存储库。团队中的一个人负责维护统称为 main 存储库的内容。

当团队成员工作时，他们可以从 main pull ，但不能推送到 main。在 pull 期间，如果存在 merge 冲突，那个人将修复他们自己的代码。

现在 main 的所有者至少需要对每个成员存储库具有读取权限。 main 的所有者然后依次从每个存储库中提取。如果没有 merge 冲突，就没有问题。如果存在 冲突，则main 的所有者中止提交，让拥有代码的人解决冲突。让我们详细了解一下这部分

1. main 从 bob pull - 好的； merge 完成并发布
2. main 从 tom pull - 冲突； merge 中止
3. main 的所有者告诉 tom 提取最新的更改并修复冲突
4. tom 可以自己解决冲突，然后告诉 main 再试一次
5. main 从 tom pull - ok

这个过程只是每天重复，或者无论您的集成周期有多频繁。

虽然这肯定会给一个人带来负担，但那个人不需要解决任何冲突，如果有正确的动机，这是一项可以自动化的工作。这是如何Linus它用于管理内核。