Git一直在合并

Question

我团队中的程序员对特定的Git存储库有一个非常奇怪的问题。

他是唯一一个对repo进行更改的用户，然而，每次推送时，Git都会发出合并提交消息，而不是实际的提交消息！

这很难解释，所以图片更适合：

在某些时候它开始做'playMakerTest'的事情，它从来没有恢复过来。 他现在制作和推送的每一次提交最终都是合并。 即使在干净地检查之后，重新定义最新的提交，将所有内容移回主人并摆脱所有其他分支。

任何人都知道为什么会这样？ 我真的处于创建新回购的边缘......

Answer 1

我不知道你是否要删除这个问题（正如上面的评论所示），但现在我会注意到一件事：

git push无法创建合并 。 ¹

当你使用git push ，你让你的git调用了一些其他的git（例如，通过ssh），之后两个git存储库进行了一些对话，讨论你的对象没有的对象，以及你的对象是什么喜欢他们设置一些他们对point-to的引用。

例如，在您的情况下，您（或者更确切地说是您团队中的程序员）可能会调用服务器git实例并说“请更改分支branch以指向提交1234567... ”。 为了让服务器这样做，服务器必须提交1234567...所以你的git可以将该对象与任何其他所需的对象打包在一起，然后将它们运送到第一个。

服务器端git在此过程中不进行任何合并，它只是接受首先需要的任何对象，然后接受诸如“set refs/heads/branch to 1234567... ”之类的请求。 这些请求通过权限检查（ pre-receive和update挂钩）运行，这通常执行诸如拒绝非快进更新之类的操作，或者当使用像gitolite这样的发烧友系统时，检查远程用户是否有权创建，删除，或更新特定分支。 ²如果权限检查允许，服务器端git进程只需设置所请求的引用（通常是分支名称，有时是标记;还有注释引用等）。

然后，在git push步骤之前，这些合并中的每一个都来自用户（而非服务器）端。 如上面的评论所述， 这是由于用户反复修改现有但被推送的提交 ，该提交将提交复制到新ID。 推送新ID不会是快速操作，默认会被拒绝; 为了实现这一点，用户可能会进行额外的合并。

---

¹不管怎么说，不是靠它自己。 使用上面提到的钩子，可以设置一个服务器，当它接收推送时，它保存任何新的提交，拒绝推送本身，然后运行其他单独的git命令以使用保存但创建合并 - 拒绝提交。 这是一种非常扭曲的操作模式，而不是人们通常或应该做的事情。 （另外，这并不是在这里创建合并的推送，它是推动触发其他脚本，另一个脚本创建合并。）

Answer 2

经过一些测试后，我确认“修改最后提交”确实是个问题。

在提交已经推送之后，修改仍将尝试更正最新提交。 一旦提交，它将注意到它刚刚被修改的提交已被推送并将引发合并冲突。

有问题的程序员错过了所有的红旗并且只是“修复”了合并冲突并推动了更改，作为一个起始的Git用户，他只是觉得它“应该是那样”。 直到其他人和我开始抱怨他的所有提交都是合并并搞乱了历史的完整性。