logo标签列表

git：如何合并经常更新的远程分支？

gitmergeworkflow
4

想知道当HEAD在合并之前可能已经更新过的情况下，合并回主分支的通常做法是什么。举例来说，在下面的图表中，M是预期的合并点，但由于在M提交并准备推送时，主分支HEAD已经被更新为A1，因此M1将成为新的预期合并点，换句话说，必须尝试进行新的合并。

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

请注意，我不想合并M和A1，因为可能会有A2、A3等问题出现，如果问题再次发生，额外的意外合并只会让问题变得更加混乱。如果本地的更改与主分支中的更改足够独立，有时我会选择在主分支上进行变基，这对我来说是一种更简单的解决方案。但有时我真的希望有一种方法可以将我为M做的合并工作“重复使用”到M1中。
每个人都有master的推送权限吗？还是由单个人维护，从团队成员的存储库中拉取代码？ - Jacob Groundwater
大家，这个过程是“总体上要遵循良好的常识”。 - prusswan
如果每个人都推送到自己的存储库，而单个人拥有“master”，这是否有帮助？该人本质上将决定如何拉取以及以哪种顺序进行。如果您愿意，我可以用答案来解释。 - Jacob Groundwater
作为仲裁者？是的，那是另一种方式，尽管我正在寻找不涉及其他人共识的东西。缺点是那个人将不得不处理所有决策，这些决策被委托给他。尽管如此，如果您将其发布为答案，我会点赞它。 - prusswan
发表，如果有任何不清楚的地方，我很愿意扩展。 - Jacob Groundwater
4个回答
2
假设团队中的每个人都维护自己的代码库。团队中的某个人维护被称为“主”代码库的集合。
在团队成员工作时，他们可以从主代码库拉取，但不能将代码推送到主代码库。在拉取过程中，如果存在合并冲突，则该人将修复自己的代码。
现在，“主”代码库的所有者至少需要读取每个成员的代码库。然后，“主”代码库的所有者依次从每个代码库中拉取。如果没有合并冲突，就没有问题。如果有冲突，则“主”代码库的所有者会中止提交，并让拥有该代码的人解决冲突。让我们详细了解这部分内容。
  1. main从bob上拉取-成功；合并已完成并发布
  2. main从tom上拉取-冲突；合并被中止
  3. main的所有者告诉tom拉取最新更改并解决冲突
  4. tom可以自己解决冲突，然后告诉main再试一次
  5. main从tom上拉取-成功

这个过程每天或每个集成周期都会重复进行。

虽然这确实将负担放到了一个人身上，但这个人不必解决任何冲突，只要有正确的动力，就可以自动化这项工作。这是Linus用于管理内核的方式。

我意识到在我们当前的流程中，任何推送合并请求到远程的人都会被隐含地要求解决与该合并相关的任何冲突。另一个问题是，许多开发人员刚刚从svn过渡，并且实际上建议他们坚持使用“main”分支，因为他们不习惯使用多个远程分支的操作思路。 - prusswan
你应该告诉他们，通过克隆一个已经在使用的仓库，他们已经在使用自己的分支。这绝对是一种不同的思考方式，我必须克服我的SVN思维。现在我更喜欢多个远程方法。 - Jacob Groundwater
从每个存储库中拉取主要内容的问题在于他们永远无法重置自己的工作。此外，我不明白主要内容将如何知道Bob何时准备好进行更改（除非每个人都在分支上工作，并且只有在准备好让主要内容获取更改时才合并到本地主要内容 - 这似乎是“它在我的环境中运行”的情况），他们可能正在进行中途工作，这是您不希望主要内容在完成之前接收到的。 - Mark Fisher
GitHub使用的策略是pull-request，每个人都会发送他们想要合并的提交。你关于rebase的说法是正确的，但是你在push之后也可以进行rebase，只是如果另一个人已经合并了你的工作，那么会变得很混乱。此外，在你想要合并某些内容之前，你不必进行push操作。 - Jacob Groundwater
1

看起来需要使用 git rebase。

工作流程

您正在一个单独的分支上工作（我们称之为 local），并进行了几次提交。 当您准备推送更改时，请切换到 master 分支并执行 git pull。然后切换回您的 local 分支并执行 git rebase master 命令。此命令将：

  1. 将您的更改/提交（在 local 上）放置在一旁，因为 master 和 local 已经分叉，
  2. 与 master 分支进行快进合并，
  3. 重新提交您在本地分支上的原始更改。请记住，提交的消息、作者和日期保持不变，但是提交哈希值会更改。这是因为所有对象（提交、树、blob）都是不可变的，由于父属性的更改，git 将创建另一个提交。

git rebase 的影响

由于提交哈希值发生了变化，你只需要在本地分支上进行变基（即那些未被推送到远程的分支）。

我其实经常这样做，但是rebase并不适用于所有情况，有时我真的希望我的功能分支的提交能够被明确地标识出来。 - prusswan
1

我们使用签入令牌来协调这种问题。持有令牌的人可以确保在发布之前没有其他人正在检入主分支。

如果您与其他开发人员共同工作并检入代码，请使用物理令牌（大象/猴子/鸡等任何东西，越可爱越好）。

当我们进行分布式开发时，我们使用一个维基页面和一个表格，其中顶部是持有“令牌”的人。

合理的想法，但我认为实际上很难说服其他开发人员这样做。其中一些人真的不在乎需要多少次合并才能推送到主分支。 - prusswan
如果出现这种情况，那就是一个流程问题。这是我们长期以来一直在做的事情，也是确保如果您拥有令牌并在测试中获得绿色条形图的关键部分，否则，如果您在合并后不重新测试，则会针对未经测试的代码进行检查。 - Mark Fisher
我同意你的想法，但仍在寻找简化我的合并工作的方法。 - prusswan
0
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接