考虑我已对个人分支中的文件进行了更改，并且我希望将我的分支合并到另一个分支（例如，development）。如果其他人也对我受影响的文件中的相同行进行了更改，则在合并分支之前需要解决冲突。我通常会做一个git pull origin development，此时Git会调出冲突并允许我修复它们。解决之后，如果我在不使用git mergetool的情况下手动打开文件，我需要git add将文件标记为已解决，＆＃34;然后我做一个git commit并接受默认的合并提交消息。
此时，我对文件所做的更改成为单一的事实来源，并将覆盖development分支中所做的更改，所以希望我没有摧毁了那个人的工作。
我的问题是，Git如何知道这是合并提交？我认为它必须知道，因为如果我对冲突解决期间制作的文件进行了完全相同的更改，然后执行了git add和git commit，那么根据定义，它将是冲突。如果我的假设不正确，请纠正我。我心里想到了这个问题因为我想知道为什么我需要将所有的分支差异都放到我的分支中来解决一个简单的小冲突文件。
答案 0 :(得分：1)
此时，我对文件所做的更改成为单一的事实来源，并将覆盖
development分支中所做的更改，因此希望我没有破坏该人的工作
“覆盖”在您的分支上进行合并提交时发生。合并提交是具有多个父项的提交，包含有关如何解决冲突的信息。当您将分支合并回development时，并不是说您的分支已成为“单一事实来源”;这是development的冲突提交已经存在于其历史中。您的分支没有进一步更改development，并且不需要覆盖任何内容。
所以，直接回答你所指出的问题：
我的问题是，Git如何知道这是合并提交？
Git 可以知道某些东西是合并提交，因为它有多个父级，但它不必知道这里开始，因为它没有任何冲突的原因合并返回不合并提交优先于正常提交。