合并更改会导致额外的签入

Question

当我提交并推送我的更改时，它会导致另一个checkin合并之前提交的其他人。例如，我更改了一个文件Readme.txt并提交它，然后执行git pull。某些更改将添加到我的存储库中。然后我推动我的改变。有一个额外的签到说：

Merge branch 'mainline' of https://example.com into mainline

如何避免这种情况，只检查我的更改？看起来这是一个重复的签到，其他人签到了。

Answer 1

您所描述的内容称为 merge-commit 。

This是一个非常好的阅读页面：

  

Git不是只向前移动分支指针，而是创建一个新的   由此三向合并自动生成的快照   创建一个指向它的新提交。这被称为a   合并提交，并且特别之处在于它有多个父级。

merge-commit 是一个提交，它汇集了两行工作，这意味着它有两个父提交，一个用于当前工作，另一个用于合并的另一端。

要避免这些提交，您可以使用 rebase 等工具在您合并的代码之上重新播放提交。这是一个复杂的主题，因此我建议您遵循一些{ {3}}首先考虑你的方向，以及一些潜在的陷阱。

rebase tutorials是一篇关于避免合并提交的文章。

Answer 2

当您通过中央存储库与他人合作时，您所看到的是正常的常见现象，不应被视为问题。这是一种处理事实的方式，即有人在您有机会推动提交之前推送了一个提交。这只是时间上的意外。

Answer 3

假设你所做的事与你所做的事之间没有冲突，通常的解决办法就是使用拉动变换：

git pull --rebase

这将做的是：

• 从远程
获取更新
• 回滚您的提交
• 将传入的提交应用到您的树
• 最后，在传入的之后重播您的本地（未推送）提交

最终结果就好像你已经做了git pull，神奇地完成了所有的更改，然后提交了它们。

如果您的本地提交与传入的提交之间存在冲突，您仍然必须执行通常的合并冲突解决方案。但如果没有，这通常会导致更清晰的历史记录和更少的合并提交。

假设您从提交A开始并进行本地提交B：

A --- B

同时，从A开始的另一位开发者添加了C，D和E：

A --- C --- D --- E

当你拉动时，会发生什么是合并两个不同的分支。最终得到最终状态F：

A --- C --- D --- E --- F
 \--- B ---------------/

如果您使用git pull --rebase，它将获得远程提交，然后在之后附加您的本地提交。所以你最终会得到这个，而且没有合并提交。

A --- C --- D --- E ---- B

（同样，假设没有发生合并冲突。）

Answer 4

快进合并可以避免这种合并提交。如果分支A和分支B的最后一次公共提交是分支A的最后一次提交但不是分支B的最后一次提交，则将B合并到A是快进合并。也就是说，A提交的序列是 B提交序列的真实子集。让我们看看这些案例。每个号码都是一个提交。

1. A：1-2-3-4，B：1-2-3-4。组（A）=集合（B）。将A合并到B或B合并为A会导致任何结果。
2. A：1-2-3-4，B：1-2-3-4-5。 set（A）是集合（B）的真实子集。合并A到B，没有任何反应。将B合并为A，默认为快进合并。
3. A：1-2-3-4，B：1-2-3-5。 set（A）的最后一次提交4不在set（B）中，而set（B）的最后一次提交5不在set（A）中。合并A到B或B到A都会导致非快速合并，就像你的情况一样。
如果可以合并，

git merge --no-ff总是进行非快进合并。 git merge --ff-only总是会失败，如果它不是快速合并的话。

您可以使用git rebase，git reset --hard和git cherry-pick将您的2个分支分配到案例2中的内容。