Question

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

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

请注意，我宁愿不合并M和A1，因为可能有A2，A3线，如果问题再次发生，它对我来说看起来太乱了，还有其他非预期的合并。如果local中的更改与master中的更改完全独立，有时我会在master之上重新定义，我发现这是一个更容易的解决方案。但在其他时候我真的希望有一些方法可以“重复使用”我为M做的合并工作，对于M1。

Answer 1

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

随着团队成员的工作，他们可以从主要部门撤离，但他们不会推向主要部门。在拉动期间，如果存在合并冲突人将修复自己的代码。

现在main的所有者至少需要对每个成员存储库的读访问权限。然后main的所有者依次从每个存储库中提取。如果没有合并冲突，没问题。如果发生冲突，那么main的所有者将中止提交，让拥有该代码的人解决冲突。让我们详细讨论这部分

main来自bob - 确定;合并完成并发布
main来自tom - 冲突;合并中止
main的所有者告诉tom提取最新更改并解决冲突
tom可以自行解决冲突，然后告诉main再试一次
main来自tom - 确定

此过程每天重复一次，或者通常是您的整合周期。

虽然它肯定会给单个人带来负担，但是那个人不必须解决任何冲突，这是一项可以在给定正确动机的情况下自动完成的工作。这就是Linus管理内核的方式。

Answer 2

它似乎是git rebase的工作。

工作流

您正在处理一个单独的分支（让我们称之为local）并且您做了一些提交。当您准备推送更改时，请检查master分支并执行git pull。检查您的local分支并执行git rebase master。该命令将：

将您的更改/提交（local）放在一边，因为master和local已分歧，
与master分支进行快进合并，
在本地分支上重新发送您的原始更改。请注意，提交的消息，作者和日期保持不变，但 提交哈希值更改。发生这种情况是因为所有对象（提交，树，blob）都是不可变的，并且由于提交的父属性发生了更改，git将创建另一个提交。

`git rebase`

由于提交哈希更改，您只需要在 LOCAL分支（即 NOT 推送到远程）上进行rebase。

Answer 3

我们使用登记令牌来协调这类问题。无论谁拥有它，都可以确保在发布之前没有其他人正在检查主人。

如果你与其他开发人员共同检查头部，那么使用一个物理标记（大象/猴子/鸡肉 - 任何真的，更可爱的）。

当我们进行分布式开发时，我们使用了一个带有表的wiki页面，其中top是具有“token”的人。

Answer 4

我终于弄明白了我的想法，解决方案就是按照此处的描述重新定义合并提交：Rebasing a Git merge commit

git：合并频繁更新的远程分支？

4 个答案:

工作流

`git rebase`