2

在制作拉取请求之前，我正在阅读有关在 Git 中压缩提交的优缺点。我没有找到有关信息的是，如果其他拉取请求被合并到主请求中，而相关拉取请求被推迟，则带有压缩提交的拉取请求是否或多或少可能会变成合并冲突。我可以想象不同的场景：

  • 通过大量的小提交，合并工具可以更容易地判断事物如何属于一起并且合并冲突的可能性较小。“合并冲突”可以“解决”成更小的单元，如果逐个考虑，这些单元不会发生冲突。
  • 对于很多小的提交，合并工具可以认为中间提交已经不可合并，即使以后的提交会修复它。（感觉有点奇怪。）
  • 从技术上讲，它没有任何区别，因为无论如何合并工具只会查看最后一次提交。

哪一个是真的，还是事情更复杂？（比如，取决于变化的种类？）

4

2 回答 2

3

如果您关心的是 running git merge，请注意git merge找到三个提交：

  • 您当前的提交，始终可以通过名称立即找到HEAD；
  • 您的合并目标--theirs/其他/“远程”提交，这是您在运行时命名的提交git merge otherbranch；和
  • 合并基础，Git 使用提交图定位。

我喜欢将这三个提交称为L（代表 Left/Local/ --ours）、R（代表 Right/Remote/ --theiRs）；和B（用于基础）。

如果您“明智地”挤压（对不起，这定义不明确！），这对合并基础查找没有影响。 L和B将是相同的。唯一的影响是R将具有不同的哈希 ID。无论您是否已压缩， R的树（保存的源快照）都是相同的。

git merge有效地做到：

git diff --find-renames B L > /tmp/ours.patch
git diff --find-renames B R > /tmp/theirs.patch

然后组合补丁，以便将组合集应用于提交B中的树。由于三棵树将保持不变，因此挤压对合并完全没有影响。

于 2018-02-14T00:02:44.120 回答
0

我至少可以想到一个实例，其中压缩的提交不太可能导致冲突：

假设您的分支中有三个两个提交，并且A是的祖先。BAB

使用A，它会更改文件顶部附近的五行和底部附近的五行。B与第一个大块相反，A将文件的该部分更改回原来的内容A~1。

A+的总更改B是文件底部附近的五行更改。

如果有人在文件顶部的五行附近更改了某些内容，则分支在合并时会发生冲突。

如果你合并A并B进入一个新的 commit C，就不会有冲突。

于 2018-02-13T22:41:00.470 回答