Git一直在合并

Question

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

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

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

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

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

Answer 1

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

git push无法创建合并。 ¹

当你使用branch时，你让你的git调用了一些其他的git（例如，通过ssh），之后两个git存储库进行了一些讨论，讨论你的gits所拥有的对象，以及你希望他们使用什么对象设置他们对point-to的引用。

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

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

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

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

Answer 2

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

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

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