7

这有点长，但我认为这可能是一个有趣的问题。

我们最近才开始在我们的公司使用 git，尽管很多人不情愿一些人设法开始在小型项目中使用它，而现在我们实际上在更多相关项目中使用它。

我总是在合并之前尝试做一个 rebase，但就在最近我们发现这种方法存在问题。

假设您有一个文件 F 并且您有以下 git 历史记录：

(master)       F -- F''1
                \
(feature)        \- F'1 -- ... -- F'X

现在，如果您对功能分支进行变基，并且在解决第一个冲突时，您实际上保留了 F''1 和 F'1 的更改，您将不得不手动解决文件 F 的 X 冲突，因为 git 可以t 自动解决它们。相反，如果您只是进行了合并（没有变基），您将只需要解决一个（“大”）冲突。这让我质疑变基的实际价值，因为这可能是一项非常乏味的工作。

我错过了什么还是这就是它的方式？如果您对一个文件有 30 次提交，则您必须检查每一次提交并手动解决任何冲突。有没有更合适的方法来处理这种情况？

很抱歉，如果我没有很好地解释，但您可以尝试复制我在虚拟存储库中提到的步骤，我想您会明白困扰我的地方。

4

1 回答 1

9

你是对的：你必须不断地重新解决冲突，通常以同样的方式。

但是，有一个用于执行此操作的自动化旋钮，称为git rerere. 三个re -s 代表re use记录re解决方案。

这样做的方式是，每次遇到冲突时，当您git add解决版本时，git 将原始冲突（减去行号）和解决方案保存在某些文件中（实际上只是存储库中的 blob 对象）。然后，在宣布冲突之前，合并代码会检查原始冲突是否已经与解决方案相关联。如果是这样，它将用该分辨率替换冲突区域。

因为在记录冲突之前行号已被删除，这通常（尽管并非总是）处理重复出现的冲突。（当周围的上下文发生变化时它会失败，因为这会改变冲突/解决对的哈希 ID。）

这有点危险，因为有时看起来相同但发生在文件中很远的冲突并不是真正的相同冲突（这往往发生在模板-y代码中）。由于每个冲突和解决方案都会被记录下来，因此您可能会积累很多解决方案并获得错误的匹配。Git 试图通过在 60 天内使记录的解决方案过期（以及在 15 天内未解决的冲突）来处理这个问题。

您必须rerere在创建第一个冲突之前启用，并在解决方案时保持启用git add。这有点烦人，因为您（好吧，我）经常发现我可能应该rerere早点启用，但现在为时已晚。我一直很想编写一个脚本，使用我现有的分辨率重复我已经解决的先前合并或变基，以输入 rerere-replay 以启动 rerere 引擎。（这个脚本的明显名称是git-rererere...... :-)）

于 2016-04-18T10:17:04.930 回答