git:合并频繁更新的远程分支?

时间:2011-11-26 09:04:09

标签: git merge workflow

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

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

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

4 个答案:

答案 0 :(得分:2)

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

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

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

  1. main来自bob - 确定;合并完成并发布
  2. main来自tom - 冲突;合并中止
  3. main的所有者告诉tom提取最新更改并解决冲突
  4. tom可以自行解决冲突,然后告诉main再试一次
  5. main来自tom - 确定
  6. 此过程每天重复一次,或者通常是您的整合周期。

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

答案 1 :(得分:1)

它似乎是git rebase的工作。

工作流

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

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

    的含义

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

答案 2 :(得分:1)

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

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

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

答案 3 :(得分:0)

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