为什么我必须在更改提交消息后强制推送？答案

【问题标题】：Why must I force push after changing a commit message?为什么我必须在更改提交消息后强制推送？
【发布时间】：2017-04-21 13:07:50
【问题描述】：

我阅读了this 关于如何修改提交消息的信息。接受的答案是：

如果您已经将提交推送到远程分支，那么您需要使用 git push <remote> <branch> --force 强制推送提交。

我的理解（也来自接受的答案）git push --force 将用本地分支覆盖远程分支上的所有数据。

为什么需要在更改提交消息后强制推送？如果我修改提交消息并尝试在没有 -f 或 --force 的情况下推送会发生什么？

【问题讨论】：

不要强迫，除非你知道你用 git 做什么。
@Stargateur 是的，因为这个原因我还没有尝试过。
'--force' 不应再使用。更喜欢'--force-with-lease'。可惜写的比较长……
@Philippe 请解释一下？
'--force-with-lease' 在删除/隐藏/丢失它们之前验证您是否获取了所有现有提交。这样，您可以确保不会无意中“删除”另一个开发人员的提交。在我新这个选项之前发生过一次。这样你就可以确保不会出错！

标签： git push git-push

【解决方案1】：

通过修改提交，您正在更改它们的 SHA1，这意味着本地和远程历史记录不再相同。

如果您想用（修改后的）本地历史记录替换远程历史记录，您需要force push。
如果你不这样做，Git 将拒绝推送，并要求你拉取（在这种情况下这没有帮助，因为你会合并相同的内容但不同的提交消息）

强制推送可能很危险，因为它forces other collaborators to reset their own local history 到新的（强制推送）一个。

正如评论，--force-with-lease is safer（如果您要更改的远程分支在您上次拉取后本身已更改，这意味着其他人正在积极使用它并将其推回，则强制推送被拒绝）。
将其与 sensible pull policy 结合使用（您总是 rebase 您尚未推送的内容），强制推送变得不那么需要了。

【讨论】：

对我来说似乎是糟糕的设计。无论个人对实践的看法如何，修改提交消息都应该是可以安全完成的事情。
@ccarton 它是 Git 设计的真正核心，它是关于数据完整性（我在这里提到：stackoverflow.com/a/27440678/6309）它通过一致性检查实现这一点：stackoverflow.com/a/28792805/6309。如果不更改所有 repo 的 SHA1，任何内容都无法更改。
是的，这就是我的观点。在不威胁“数据完整性”的情况下，您无法安全地修改提交消息这一事实对我来说似乎是短视的设计。我接受今天的 git 可能无法更改以支持这一点，但这不是重点。
@ccarton 这是一个很好的设计，即使有时会带来不便，也会带来很多好处。如果你真的需要，也许你应该使用'git notes'。
@ccarton 请注意，您可以修改本地存储库中的提交，直到将它们推送到远程存储库，这本身应该是一个决策点，而不仅仅是一个自动操作。

【解决方案2】：

我的理解（也来自已接受的答案）git push --force 将用本地分支覆盖远程分支上的所有数据。

通过修改提交，您已经覆盖了您的 git 历史记录（通过更改提交的 SHA1）。 Amend 只要你没有发布你的更改就可以了，但是一旦你这样做了，你真的不应该在历史上乱七八糟，因为如果有人已经得到了你的更改，那么当他们再次尝试拉动时，它可能会失败。与其修改提交，不如只对更改进行新的提交。

如果我修改提交消息并尝试在没有 -f 或 --force 的情况下推送会发生什么？

Git 将拒绝用你的分支更新远程分支（修改公共提交），因为你的分支的头部提交不是你推送到的分支的当前头部提交的直接后代。

如果不是这样，那么两个人几乎同时推送到同一个存储库将不知道同时有一个新的提交进来，最后推送的人将失去前一个推送者的工作他们中的任何一个都没有意识到这一点。

为什么需要在更改提交消息后强制推送？

正如我上面提到的，git 不允许推送到远程分支。你可以阅读这个question。这个问题有很多可能的解决方法。

【讨论】：