问题描述
关于强制 git push 的问题和答案并不难找到(这里 是两个).标准答案是这样的:
Questions and answers about forcing a git push aren't hard to find (here are two). The standard answer goes something like this:
如果您必须强制执行 git push，技术上您可以使用 --force 选项，但程序上您应该't 因为有人可能已经拉过，小猫会死在某个地方.
我认为这通常是明智的建议 - 更安全的方法是再次提交，修复你破坏的任何东西.但是让我们说例如我知道(神奇地)还没有人撤回提交.或者更好的是，这是一个私人存储库，因此一开始就没有破坏任何其他人的克隆的危险.
I see this as generally sage advice - the safer route is to just commit again, fixing whatever you broke. But let's say for example I know (magically) that no one has pulled the commit(s) yet. Or better still, that this is a private repo and so there's no danger of breaking anyone else's clone in the first place.
--force 推送是否有任何other [负面] 后果，特别是技术后果?也许它会在遥控器中造成一些额外的垃圾，或者它破坏了 X Corps 分析工具的 1.2.3 版本，或者它使以后的 rebase 更加混乱等等.有什么吗?
Are there any other [negative] consequences of --forceing a push, specifically technical consequences? Maybe it causes some extra garbage in the remote, or it breaks version 1.2.3 of X Corps' analysis tool, or it makes rebasing more confusing later on, etc.. Anything?
编辑 1:我有自己的轶事证据表明 --force 推动私人存储库似乎造成任何问题.不过，我对感知不感兴趣；我正在寻找参考资料和/或证明.
EDIT 1: I have my own anecdotal evidence suggesting that --forceing a push on a private repo doesn't seem to cause any problems. I'm not interested in perception, though; I'm looking for references and/or proof of such.
推荐答案
强制推送只是告诉遥控器移动给定的标签，即使移动不是快进操作. 非快进可能(不一定)导致放弃"提交:无法从某些引用中访问的提交.
A force-push merely tells the remote to move the given label(s) even if the move is not a fast-forward operation. A non-fast-forward can (does not necessarily) result in "abandoned" commits: commits that are no longer reachable from some reference.
(当标签移动发生在其他地方引用的图的一部分时，它不会这样做.例如，如果分支 xyzzy 指向提交 D 在序列中:
(It does not do this when the label motion occurs on a part of the graph that is referenced elsewhere. For instance, if branch xyzzy points to commit D in the sequence:
A-B-C-E <-- plugh
/
D <-- xyzzy
那么标签 xyzzy 发生了什么无关紧要，因为标签 plugh 使得提交 D 可达.因此，以非快进方式将 xyzzy 移动到例如指向提交 C 根本不会影响提交 D.同样，完全删除标签 xyzzy 也是无害的，至少在提交图结构方面是这样.)
then it is irrelevant what happens to label xyzzy, as label plugh makes commit D reachable. So moving xyzzy in a non-fast-forward fashion to, e.g., point to commit C does not affect commit D at all. Likewise, deleting label xyzzy entirely is also harmless, at least in terms of the commit graph structure.)
远程裸仓库(通常推送到的仓库)通常不会记录所有引用更新，因此这往往会触发对任何放弃提交的快速垃圾收集.(请注意，如果您将它们保存在您自己的存储库中，您可以稍后恢复 gc'ed 提交 - 但这需要您再次通过网络发送数据，并且如果您自己的存储库通过以下方式损坏，您将面临数据丢失风险，例如、电源故障或您的计算机着火.)
Remote bare repositories (to which one generally pushes) often do not log all ref updates, so this tends to trigger rapid garbage-collection of any abandoned commits. (Note that if you keep them in your own repository, you can restore gc'ed commits later—but that requires that you send the data over the network again, and exposes you to data loss risk if your own repo gets corrupted via, say, a power failure, or your computer catching on fire.)
如果您有一些第三方软件假定(部分或全部)分支标签仅以快进方式移动，则所述软件可能会以有趣的方式失败.我知道没有这样的软件，如果它存在，我会称它为损坏的"，但人们似乎经常编写损坏的代码然后依赖它.
If you have some third-party software that assumes that (some or all) branch labels only move in fast-forward fashion, said software could fail in interesting ways. I know of no such software and if it exists I would call it "broken", but people do often seem to write broken code and then depend on it.
如果移动是快进的，旧版本的 git 允许标签在没有强制推动的情况下移动，就像分支标签应该移动的方式一样.较新的版本(我认为是在 1.8.2 中引入的，但这只是出于记忆)拒绝任何标签运动，除非您使用强制.当然，你总是可以删除，然后重新创建(可能在不同的点)，一个标签，内置的钩子就可以了.因此，还有其他方法可以以任意方式移动标签或分支，甚至无需用力.只需确保您要保留的提交图部分在每个操作中都有一些标签.
Older versions of git allowed tags to move without a force-push if the move was fast-forward, in the same way that branch labels are expected to move. Newer versions (I think introduced in 1.8.2, but that's just from memory) reject any tag motion unless you use force. Of course you can always delete, then re-create (possibly at a different point), a label, and the built-in hook is OK with that. So there are other ways to move a tag or branch, in arbitrary fashion, even without force. Just make sure the parts of the commit graph you want to retain have some label across each operation.
至于使(您自己的)重新变基更难:是的，它可以产生这种效果，因为您可能会从桌面"强制推送，从而实际上重新排列共享裸机"-回购".稍后，在笔记本电脑"上，您可能无法仅记住 哪些提交是您重新定位的，并且弄清楚它可能有点棘手，尤其是在大型、高度活跃的存储库中.
As for making (your own) rebasing harder later: yes, it can have that effect, because you might force-push from "desktop" and thus, in effect, rearrange "shared-bare-repo". Later, on "laptop", you might not be able to remember just which commits you rebased, and figuring it out can be a little tricky, especially in a large, highly-active repository.
幸运的是，即将发布的新 git 版本有一个新功能，它使用您的 reflog 来确定是否以及何时发生了上游变基".也就是说，在上述情况下，您将能够(在笔记本电脑"上)要求 git 自动发现哪些提交在 shared-bare-repo 中被重新定位，并重新定位"您的笔记本电脑在其上的工作.(这是今天在 git 1.8.x 中与 git pull --rebase 一起使用的方法的概括.)
Fortunately, the new upcoming git release has a new feature that uses your reflogs to figure out if and when an "upstream rebase" has occurred. That is, in the above situation, you would be able (on "laptop") to ask git to automatically discover which commits were rebased in shared-bare-repo and "re-rebase" your laptop work on that. (This is a generalization of the method used with git pull --rebase today, in git 1.8.x.)
这篇关于`git push --force` 的其他后果?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！