压缩提交是否会影响合规性？

Question

我正在阅读在制作拉取请求之前在Git中压缩提交的利弊。我没有找到关于的信息是，如果其他拉取请求被合并到主服务器中，当有问题的拉取请求被推迟时，带有压缩提交的拉取请求是否更有可能变成合并冲突。我可以想象不同的场景：

• 通过大量的小型提交，合并工具可以更轻松地说明事物的组合方式，并且合并冲突的可能性较小。如果逐一考虑，“合并冲突”可以“解决”为较小的单位，这些单位不会发生冲突。
• 通过大量小提交，合并工具可以考虑中间提交已经无法合并，即使稍后的提交会修复它。 （感觉有点奇怪。）
• 从技术上讲，它没有任何区别，因为合并工具只会查看最后一次提交。

哪一个是真的，还是更复杂的东西？ （比如，取决于变化的类型？）

Answer 1

如果您关注的是运行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

然后组合这些补丁，以便将组合集应用于commit B 中的树。由于三棵树将保持不变，挤压对合并没有任何影响。

Answer 2

我可以想到至少有一个实例，其中一个压扁的提交 less 可能会导致冲突：

假设您的分支中有三个提交，A和B，A是B的祖先。

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

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

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

如果您将A和B合并到新的提交C中，则不会发生冲突。