我已经设置了一个远程非裸机“主”存储库，并将其克隆到我的计算机上。我做了一些本地更改，更新了本地存储库，并将更改推回到远程存储库。当时一切都很好。
现在，我必须在远程回购中更改一些内容。然后，我在本地回购中更改了一些内容。我意识到不需要对远程回购进行更改。所以我尝试从本地回购机向远程回购机进行git推送，但出现了如下错误：
为了防止您丢失历史记录拒绝在再次推送之前合并远程更改。参见“注释”git push的“关于快进”部分--有关详细信息的帮助。
我想那可能是
git push --force
将强制我的本地副本将更改推送到远程副本并使其保持不变。它确实会强制更新，但当我返回到远程回购并提交时，我注意到文件包含过时的更改（主远程回购以前的更改）。
正如我在对其中一个答案的评论中提到的：
[一] 尝试强制，但当返回主服务器保存更改时，我得到了过时的暂存。因此，当我提交时，存储库并不相同。当我再次尝试使用git push时，我得到了同样的错误。
如何解决此问题？
首先，我不会直接对“主”回购协议进行任何修改。如果你真的想有一个“主”回购，那么你应该只推动它，而不是直接改变它。
关于您遇到的错误，您是否尝试过从本地回购中提取git，然后将git推送到主回购？你目前正在做的事情（如果我理解得很好的话）是强制推送，然后失去“主”回购中的更改。您应该首先在本地合并更改。
我真的建议：
仅推送至主回购确保主回购是一个裸回购，以避免主回购工作树与其.git库不同步。请参阅“How to push a local git repository to other computer？”如果您确实需要在主（裸机）存储库中进行修改，请克隆它（在主服务器上），进行修改并推回到它
换言之，保持可以从主服务器和本地计算机访问的裸回购，以便有一个从/从中提取/提取的上游回购。
只要做到：
git push origin <your_branch_name> --force
或者如果您有特定回购：
git push https://git.... --force
这将删除您以前的提交并推送当前提交。
这可能不合适，但如果有人偶然发现这一页，认为他们可能需要一个简单的解决方案。。。
短标志
还要注意，-f是--force的缩写，因此
git push origin <your_branch_name> -f
也会起作用。
如果push-force不起作用，你可以执行push-delete。查看此实例的第二行：
git reset --hard HEAD~3 # reset current branch to 3 commits ago
git push origin master --delete # do a very very bad bad thing
git push origin master # regular push
但要小心。。。
永远不要回顾公开的历史！
换句话说：
不要强制推送公共存储库。不要做这件事或任何可能破坏某人的吸引力的事。不要在某人可能已经撤销的回购中重置或重写历史。
当然，即使是这条规则也有异常罕见的例外，但在大多数情况下，不需要这样做，这会给其他人带来问题。
改为执行还原。
而且，在向公众回购时，一定要小心。正在还原：
git revert -n HEAD~3..HEAD # prepare a new commit reverting last 3 commits
git commit -m "sorry - revert last 3 commits because I was not careful"
git push origin master # regular push
实际上，两个原始HEAD（来自恢复和来自错误重置）将包含相同的文件。
edit添加更新的信息和更多关于push-force的参数
考虑使用租赁而不是推，但仍倾向于恢复
另一个问题是，当有人在你做任何事情之前，但在你已经取得任何东西之后，用力可能会带来。如果你现在强制你的重基版本，你将替换其他人的工作。
git推送——git 1.8.5中引入的带有租约的force（感谢@VonC对这个问题的评论）试图解决这个特定问题。基本上，如果在最近一次获取后修改了遥控器，它会带来错误，而不会推送。
如果你真的确定需要推动，但仍然想防止更多的问题，这是很好的。我想说，这应该是默认的强制行为。但这还远远不是强行推动的借口。那些在你回归之前就已经回归的人仍然会有很多麻烦，如果你回归的话，这些麻烦是很容易避免的。
既然我们讨论的是git——push实例。。。
为什么有人想强行推？
@linquize在评论中提供了一个很好的推动力示例：敏感数据。你错误地泄露了不应该推送的数据。如果你足够快，你可以通过顶推来“修复”它。
*除非您同时进行垃圾收集或以某种方式清理，否则数据仍将位于远程。还有一个很明显的可能性，那就是它可能会被其他已经拿到它的人传播，但你明白了。
这是我们在维护历史的同时替换企业gitHub存储库上的master的解决方案。
公司存储库上的push-f to master通常被禁用以维护分支历史。这个解决方案对我们有效。
git fetch desiredOrigin
git checkout -b master desiredOrigin/master // get origin master
git checkout currentBranch // move to target branch
git merge -s ours master // merge using ours over master
// vim will open for the commit message
git checkout master // move to master
git merge currentBranch // merge resolved changes into master
将您的分支推到desiredOrigin并创建PR
我也有同样的问题，但最终还是想通了。您最可能需要做的是运行以下两个git命令（用gitcommit修订号替换hash）：
git checkout <hash>
git push -f HEAD:master
如果您正在使用Github访问令牌进行身份验证，请尝试以下操作：
git远程设置url源https://YourTokenNum@github.com/UserName/项目名称git push—force—设置上游原始主机
我的问题是——我做到了：
git checkout arbitrary_commit
git push origin master --force
这不是正确的做法。相反，我必须：
git reset HEAD~3
git push origin master --force
注：数字3只是一个例子。你应该输入自己的号码。
gitpush-force可以完成任务，尽管gitpush-foforcewithlease是一个更安全的命令
gitpush-force覆盖远程分支，而gitpush-foforce with lease仅在本地副本知道远程分支上的所有提交时才覆盖远程分支。这种差异使破坏其他人对项目的更改变得更加困难。
在租约中使用--force可能是更好的选择：
git push <remote> <branch> --force-with-lease
它确保在您修改分支之前没有人更新过它，因此您不会覆盖他们的更改。
