我的团队将存储库存储在GitHub中。如果文件（file1）已被developer1（在本地存储库中）修改并提交到远程存储库。现在另一个人（developer2）在他的本地仓库中修改了同一个文件而没有从远程仓库同步最新的，更改被提交到远程仓库（强制推送）。 GitHub远程存储库或git客户端没有警告（我们使用Tortoise Git客户端或eGit）。请通过在远程存储库或git客户端中进行任何设置更改来建议是否有办法防止这种情况。
可能需要git hooks中的一些设置吗？
答案 0 :(得分：2)
更改将提交到远程仓库（强制推送）
只有当做出推动的人竭尽全力强迫它时，才会发生这种情况。
这就是你的问题：人们决定明确地覆盖他们没有做过的工作。
在Git中，你做了
git config receive.denyNonFastForwards true
git config receive.denyDeletes true
（并且接收端有更多可用的粒度，请参阅git配置文档）以阻止人们将其用于回购。
GitHub不允许直接访问该级别的存储库管理，它们是前端。他们称他们的调味品为＆＃34; protected branches＆＃34;。
答案 1 :(得分：0)
更新 - 问题最初没有指定强制推送。这完全改变了答案（虽然不是提问者可能会欣赏的方式）;保留原始答案以供参考，因为它仍然是协调变化的正确方法。
强制推动具体意味着推动的人想要覆盖历史。如果不是这样，那么就不应该使用推力。通常这种问题组合意味着有人试图推动，当他们遇到需要先同步的错误时，认为强制推动听起来更容易。
由于强制推送意味着“我想覆盖历史记录”，因此git不会响应警告您即将覆盖历史记录。
您可以使用--force-with-lease代替--force。这允许你特意告诉git 你希望从历史中覆盖什么，如果你实际上覆盖的历史不同于git，git会使操作失败并警告你（因为有人推了一些你还不知道的东西）。
但是，“增加安全性”仍然不足以使推力属于您的日常工作流程。在99.99999％的情况下，更好的解决方案是培训您的开发人员不要强制推送，而是通过常规推送来表达git给出的错误，这可以告诉您确切需要将您的更改与队友的更改同步。
原始答案：
你的问题标题中的前提是不正确的;第二个开发人员更改不“覆盖”第一个开发人员更改。
集成更改的点是在repos与push和fetch（或pull）之间进行同步时。每个本地仓库（克隆）都是一个独立的仓库，用户可以 - 并且必须能够 - 提交，而不必担心其他人是否已经提交到不同仓库中的相应分支。
由于您希望GitHub警告developer2，我认为这意味着developer1已经提交并推动了他们的更改。这很好。所以现在developer2提交了一些更改，尚未从远程更新。还好。现在当developer2尝试推送时，会出现错误，说明developer2的分支不是最新的。 那是git避免丢失developer1的变化的方式。
因此，developer2将被告知在允许推送之前获取并合并（或重新绑定）或拉取最新的更改。
git模型是分布式开发之一。开发人员必须能够独立提交，事实上，您不希望尝试合并尚未提交的更改，因为如果出现问题，您可能会丢失这些更改。因此，合并总是在本地完成，并且始终在提交的更改中完成。