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

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

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

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

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

最佳答案 我不知道你是否要删除这个问题(正如上面的评论所示),但现在我会注意到一件事：

git push无法创建合并

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

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

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

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

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