我的本地存储库包含所有提交。 最近有人清除了远程存储库中的所有代码并提交。 现在我想将我的本地代码推送到存储库。
当我尝试推送（git push origin master）时出现错误
(non-fast-forward)
error: failed to push some refs to 'https://myurl.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull') before pushing again.
当我在日志中尝试“git origin pull master”时，它显示多个文件被删除。 我通过使用硬重置@{14:30} 进行了恢复。
建议使用 git push -f origin master。 如果我执行强制推送命令，我的远程历史记录会与本地历史记录相同吗？
答案 0 :(得分：0)
TL;DR：是的。这将丢弃远程存储库中的一些历史记录，并将其替换为您拥有的历史记录。 您可能不应该这样做。
更长：
<块引用>最近有人清除了远程仓库中的所有代码并提交了。
这意味着这个人，无论他是谁，都有能力删除你的提交。即使您通过 git push --force 将它们完全恢复原样，有什么可以阻止此人再次删除它们？同时，他如何看待你删除他提交的行为？你们两个将在这个远程存储库上进行一场战争。 这是个好主意吗？
建议使用 git push -f origin master。
由谁建议？
请记住，在 Git 存储库中，历史记录不是而是提交，通过分支名称（以及标签名称和其他名称）找到。提交已编号。数字看起来是随机的（但实际上不是）；每个数字对于该特定提交都是唯一的。数字以 hexadecimal 表示。
每个提交本身有两个部分：
提交具有每个文件的完整快照。这使得提交是独立的，就像这样：如果你有提交，你就有它的所有文件。否则（你没有提交），你就没有它的文件。
而且，一个提交有一些元数据：关于提交本身的信息，例如谁做出的，以及何时（作者和提交者姓名和电子邮件以及两个日期和-时间戳）。包含在此元数据中的每个提交都记录了其直接前任的原始提交编号。
通过这种方式，提交形成了向后看的链。在一个只有三个提交的小型存储库中，我们可能会有这样的：
A <-B <-C <--master
其中大写字母代表提交的哈希 ID。
您在这里的建议是有人放弃了一些提交并至少提交了一个新提交：
A <-D <--master
如果您使用 git push --force master，您将发送它们（位于 origin 的存储库）再次提交 B 和 C：
A <-B <-C
\
D <--master
然后命令他们，而不是礼貌地要求他们，让他们的master再次提交C：
D
/
A <-B <-C <--master
Commit D 现在“丢失”（unreachable 是技术术语），因为 Git finds 提交的方式是以名称开头，例如master，指向某个系列中的最后次提交，然后向后工作。向后工作的结果是提交列表。这就是历史。
通过使 name 指向不同的 last 提交，您可以更改历史记录。如果您的更改只是添加一个新提交，则这会添加历史记录：
A <-B <-C <-E <--master
这将添加到 A-B-C 历史中，产生一个 E-C-B-A 历史，如从最后向后工作所见。
带有 push 的 force 选项意味着 我知道这会丢弃一些历史记录；无论如何都要这样做，接收方的 Git 可以服从也可以不服从。
答案 1 :(得分：0)
git push -f origin master
应该对你有用，上面的 git 命令只对第一次提交安全有效。如果之前已经有提交、拉取请求或分支，这将重置所有这些并将其从零设置
答案 2 :(得分：0)
如果您强制推送到会使远程历史记录与本地历史记录相同的分支。
为了避免这个问题，您可以使用不允许强制推送分支的受保护分支功能，这对于主分支或默认分支是可取的，因此没有人可以通过强制推送删除代码。
更新：
这也取决于其他用户如何删除所有代码，如果他删除了代码并强制推送，那么您将不得不再次强制推送，但他刚刚删除了所有代码，提交然后推送，然后您可以revert 他不需要任何强制推送的提交。您可以使用以下方法恢复：
git revert <commit-hash>
您必须先使用远程分支更新您的分支。
如果您不确定这一切，只需备份您的文件夹，然后执行实验。