Git 一直合并
Git merges all the time
我团队中的一名程序员对特定 Git 存储库有一个非常奇怪的问题。
他是唯一对存储库进行更改的用户，但是，每次他推送时，Git 都会生成合并提交消息，而不是实际的提交消息！
很难解释所以一张图片更适合：
在某个时候它开始做 'playMakerTest' 的事情并且它再也没有从中恢复过来。他现在做出和推动的每一次提交最终都是一次合并。即使在干净地签出之后，rebase 最新的提交，将所有内容移回 master 并删除所有其他分支。
有人知道为什么会这样吗？我真的快要创建一个新的存储库了...
我不知道你是否要删除这个问题（如上面评论中所建议的），但现在我要注意一件事：
git push 无法创建合并.1
当您使用 git push 时，您的 git 调用其他一些 git（例如，通过 ssh），之后两个 git 存储库有一个讨论您的哪些对象有哪些对象没有，以及您希望他们将哪些对象的某些引用设置为指向。
例如，在您的情况下，您（或者更准确地说是您团队中的程序员）可能会调用服务器 git 实例并说 "please change branch branch to point to commit 1234567..."。为了让服务器做到这一点，服务器必须 有 提交 1234567... 这样你的 git 就可以将该对象与任何其他需要的对象打包，然后发送先说这些。
服务器端git 在这个过程中不会做任何合并，它只是先接受任何需要的对象，然后接受像[=50=这样的请求].这些请求是 运行 通过权限检查（pre-receive 和 update 挂钩），通常会做一些事情，比如拒绝非快进更新，或者在使用像 [=51= 这样更高级的系统时]olite，检查远程用户是否有权创建、删除或更新特定分支。2 如果权限检查允许，服务器端 git 进程简单设置请求的引用（通常是分支名称，有时是标签；还有注释引用等）。
然后，这些合并中的每一个都来自用户（而非服务器）端，在 git push 步骤之前。如上面的评论所述这是由于用户反复修改现有但推送的提交，将提交复制到新 ID。推送新 ID 不会是快进操作，默认情况下会被拒绝；为了让它发生，用户可能正在做额外的合并。
1好吧，反正不是靠它自己。使用上面提到的钩子，可以设置一个服务器，这样当它收到推送时，它会保存任何新的提交，拒绝推送本身，然后 运行s 额外的单独 git使用保存但拒绝的提交创建合并的命令。这是一种相当扭曲的操作模式，不是人们通常会或应该做的事情。 （此外，这里不完全是推送创建合并，而是推送触发其他脚本，其他脚本创建合并。）
经过一些测试，我确认 "Amend Last Commit" 确实是问题所在。
提交已经被推送后，amend 仍会尝试更正最新的提交。提交后它会注意到它刚刚修改的提交已经被推送并且会抛出合并冲突。
有问题的程序员错过了所有危险信号，只是 "fixed" 合并冲突并推送了更改，作为起始 Git 用户，他只是认为是 "supposed to be that way"。直到其他人和我开始抱怨他的所有提交都是合并并破坏了历史完整性。
我团队中的一名程序员对特定 Git 存储库有一个非常奇怪的问题。
他是唯一对存储库进行更改的用户，但是，每次他推送时，Git 都会生成合并提交消息，而不是实际的提交消息！
很难解释所以一张图片更适合：
在某个时候它开始做 'playMakerTest' 的事情并且它再也没有从中恢复过来。他现在做出和推动的每一次提交最终都是一次合并。即使在干净地签出之后，rebase 最新的提交，将所有内容移回 master 并删除所有其他分支。
有人知道为什么会这样吗？我真的快要创建一个新的存储库了...
我不知道你是否要删除这个问题（如上面评论中所建议的），但现在我要注意一件事：
git push 无法创建合并.1
当您使用 git push 时，您的 git 调用其他一些 git（例如，通过 ssh），之后两个 git 存储库有一个讨论您的哪些对象有哪些对象没有，以及您希望他们将哪些对象的某些引用设置为指向。
例如，在您的情况下，您（或者更准确地说是您团队中的程序员）可能会调用服务器 git 实例并说 "please change branch branch to point to commit 1234567..."。为了让服务器做到这一点，服务器必须 有 提交 1234567... 这样你的 git 就可以将该对象与任何其他需要的对象打包，然后发送先说这些。
服务器端git 在这个过程中不会做任何合并，它只是先接受任何需要的对象，然后接受像[=50=这样的请求].这些请求是 运行 通过权限检查（pre-receive 和 update 挂钩），通常会做一些事情，比如拒绝非快进更新，或者在使用像 [=51= 这样更高级的系统时]olite，检查远程用户是否有权创建、删除或更新特定分支。2 如果权限检查允许，服务器端 git 进程简单设置请求的引用（通常是分支名称，有时是标签；还有注释引用等）。
然后，这些合并中的每一个都来自用户（而非服务器）端，在 git push 步骤之前。如上面的评论所述这是由于用户反复修改现有但推送的提交，将提交复制到新 ID。推送新 ID 不会是快进操作，默认情况下会被拒绝；为了让它发生，用户可能正在做额外的合并。
1好吧，反正不是靠它自己。使用上面提到的钩子，可以设置一个服务器，这样当它收到推送时，它会保存任何新的提交，拒绝推送本身，然后 运行s 额外的单独 git使用保存但拒绝的提交创建合并的命令。这是一种相当扭曲的操作模式，不是人们通常会或应该做的事情。 （此外，这里不完全是推送创建合并，而是推送触发其他脚本，其他脚本创建合并。）
经过一些测试，我确认 "Amend Last Commit" 确实是问题所在。
提交已经被推送后，amend 仍会尝试更正最新的提交。提交后它会注意到它刚刚修改的提交已经被推送并且会抛出合并冲突。
有问题的程序员错过了所有危险信号，只是 "fixed" 合并冲突并推送了更改，作为起始 Git 用户，他只是认为是 "supposed to be that way"。直到其他人和我开始抱怨他的所有提交都是合并并破坏了历史完整性。