我们认为这是一个典型的git设置，有一个“origin”存储库，多个用户，每个用户都有自己的存储库，提取和推送，每个用户管理自己的分支，然后合并到主分支。
然而，来自用户的提交和推送导致另一个用户被撤消的更改：两个用户都修改了相同的文件，我希望并且期望这些更改将合并在一起，我就是相当肯定这个提交没有显示任何与冲突有关。
我不确定如何调查发生的事情，更不用说如何防止再次发生这种情况。我怎样才能知道发生了什么，以及将来可以做些什么来阻止它？
编辑：从@antak的回答请求澄清，更改是“撤消”而不是从历史记录中删除提交，但是从git show看起来，他们手动删除了他们的更改（但他们没故意这样做。）
答案 0 :(得分：1)
问他们是否使用push -f？如果使用-f标志，它将使用您的更改覆盖分支，而不考虑其他更改。可能发生了一个开发人员尝试推送，git拒绝推送，因为自从他开始工作以来已经发生了其他更改，并且不知道他应该使用fetch / pull / merge，并且只是做了推-f。
如果结果是这种情况，你可以考虑在git服务器上将receive.denyNonFastForwards设置为true，这将禁止重写历史记录（反过来，使用push -f来破坏其他更改）
答案 1 :(得分：1)
用户A推送和解除用户B在文件C中的工作...
如何定义“撤消”？ B的提交是否从历史中消失了？
如果答案是否定的，可能会发生以下情况：
A拉了。A 在工作树中覆盖文件C，其中包含他/她在其他地方修改过的旧版本。A已提交并推送。您可以通过使用C等选项查看git log -p的历史记录，轻松确定是否属于这种情况。
如果答案是肯定的，唯一可能发生这种情况的方法（git中的小故障）是A推送git push -f。如果是这种情况，您可以通过拒绝非快进推送到origin来防止将来发生这种情况。这可以通过在git config的存储库中将receive.denyNonFastForwards变量true设置为origin来完成。
答案 2 :(得分：0)
我们发现了正在发生的事情。一个用户从他们自己的git存储库远程编辑文件，并通过SCP上传更改的文件。他们也在获取/合并到此存储库，但是不总是将更改的文件下载到他们的本地工作区。所以事件链：