我团队中的一位程序员在使用特定 Git 存储库时遇到了一个非常奇怪的问题。
他是唯一对存储库进行更改的用户，然而，每次他推送时，Git 都会生成 merge 提交消息，而不是实际的提交消息!
很难解释所以一张图片更适合:
在某个时候，它开始做“playMakerTest”的事情，而且它再也没有从中恢复过来。他现在做出和 push 的每一次提交最终都是一次 merge 。即使在干净地 checkout 之后，rebase 最新的提交，将所有内容移回 master 并删除所有其他分支。
有人知道为什么会这样吗？我真的快要创建一个新的存储库了...
最佳答案
我不知道你是否要删除这个问题(如上面评论中所建议的)，但现在我要注意一件事:
git push 无法创建 merge 。1
当你使用 git push 时，你会让你的 git 调用一些其他的 git(例如，通过 ssh)，之后这两个 git 存储库会进行一些对话来讨论你的哪些对象是他们的没有，以及您希望他们将哪些对象的某些引用设置为指向。
例如，在您的情况下，您(或者更准确地说是您团队中的程序员)可能会调用服务器 git 实例并说“请更改分支 branch 以指向提交 1234567。 ..”。为了让服务器执行此操作，服务器必须有提交 1234567... 这样您的 git 就可以将该对象与任何其他需要的对象打包，然后发送这些对象结束，先。
服务器端的 git 不在此过程中做任何 merge ，它只是先接受任何需要的对象，然后接受像“set refs/heads/branch”这样的请求> 到 1234567...”。这些请求通过权限检查(pre-receive 和 update Hook )运行，通常会执行诸如拒绝非快进更新之类的操作，或者在使用诸如gitolite，检查远程用户是否有创建、删除或更新特定分支的权限。2 如果权限检查允许，服务器端 git 进程简单地设置请求的引用(通常是分支-名称，有时是标签；还有注释引用等)。
然后，这些 merge 中的每一个都来自用户(而非服务器)端，在 git push 步骤之前。如上面的评论所述，这是由于用户反复修改现有但已推送的提交，这会将提交复制到新 ID。推送新 ID 不会是快进操作，默认情况下会被拒绝；为了实现它，用户可能正在执行额外的 merge 。
1好吧，不管怎样，不是靠它自己。使用上面提到的钩子(Hook)，可以设置一个服务器，这样当它接收到一个推送时，它会保存任何新的提交，拒绝推送本身，然后运行额外的单独的 git 命令来使用保存的但创建 merge -拒绝提交。这是一种相当扭曲的操作模式，不是人们通常会或应该做的事情。 (另外，这里不完全是推送创建 merge ，而是推送触发其他脚本，其他脚本创建 merge 。)
关于Git 一直在 merge ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31276991/