强制“ git push”覆盖远程文件

#1 楼

您应该能够通过使用

git push -f <remote> <branch>

（例如git push -f origin master）将本地修订版本强制到远程仓库。取消<remote>和<branch>将会强制推送设置了--set-upstream的所有本地分支。

请注意，如果其他人共享此存储库，其修订历史将与新存储库冲突。并且如果它们在更改点之后有任何本地提交，它们将变得无效。

更新：以为我会添加一个旁注。如果您正在创建其他人可以查看的更改，那么创建具有这些更改的分支并定期重新设置基础以使它们与主要开发分支保持最新的情况并不少见。只是让其他开发人员知道这会定期发生，这样他们就会知道会发生什么。

更新2：由于观看者的数量不断增加，我想添加一些其他信息，以了解在什么时候该做什么您的upstream确实受到了强制推动。

说我已经克隆了您的存储库，并添加了一些类似的提交：

            D----E  topic
           /
A----B----C         development

但是稍后development分支被rebase击中，这将导致我在运行git pull时收到类似的错误：

Unpacking objects: 100% (3/3), done.
From <repo-location>
 * branch            development     -> FETCH_HEAD
Auto-merging <files>
CONFLICT (content): Merge conflict in <locations>
Automatic merge failed; fix conflicts and then commit the result.

这里我可以解决冲突和commit ，但这会让我留下一个非常丑陋的提交历史记录：

       C----D----E----F    topic
      /              /
A----B--------------C'  development

使用git pull --force看起来很吸引人，但是要小心，因为那样会使您陷入搁浅的提交状态：

            D----E   topic

A----B----C'         development

所以最好的选择是做一个git pull --rebase。这将需要我像以前一样解决所有冲突，但是对于每个步骤，我将使用git rebase --continue而不是提交。最终，提交历史看起来会好得多：

            D'---E'  topic
           /
A----B----C'         development

更新3：您还可以将--force-with-lease选项用作“更安全”的强制方式，如Cupcake在他的
答案中所述：


带有“租赁”的强制推动将使强制推动失败（
）是您没想到的远程上的新提交（从技术上讲，如果您尚未将它们提取到远程跟踪分支中），如果您不想意外地使用它，
很有用覆盖您甚至还不知道的其他人的提交，而您只想
覆盖自己的：

git push <remote> <branch> --force-with-lease

您可以通过阅读以下任何内容，了解有关如何使用--force-with-lease的更多详细信息：


git push文档
Git：如何忽略快速前进和还原原点[分支]要更早提交？

#2 楼

您想强制推送

您基本上想要做的就是强制推送本地分支，以便覆盖远程分支。

如果您需要更详细的说明下面的每个命令，请参阅下面的“我的详细信息”部分。基本上，您可以使用Git进行4种强制推送：

 git push <remote> <branch> -f
git push origin master -f # Example

git push <remote> -f
git push origin -f # Example

git push -f

git push <remote> <branch> --force-with-lease
 

如果需要有关每个命令的更详细说明，请参阅下面的详细答案部分。

警告：强制推送将用您推送的分支的状态覆盖远程分支。在使用它之前，请确保这是您真正想要做的，否则您可能会覆盖您实际上想要保留的提交。

强制推送详细信息

指定远程和分支

您可以完全指定特定的分支和远程。 -f标志是--force的简写

git push <remote> <branch> --force
git push <remote> <branch> -f

省略分支

当省略分支以压入分支时，Git会考虑它根据您的配置设置。在2.0之后的Git版本中，新的存储库将具有默认设置以推送当前已签出的分支：

git push <remote> --force

在2.0之前的版本中，新的存储库将具有默认设置推动多个本地分支机构。有问题的设置是remote.<remote>.push和push.default设置（请参见下文）。

省略遥控器和分支机构

当省略遥控器和分支机构时，只是git push --force是由您的push.default Git配置设置决定的：

git push --force

从Git 2.0开始，默认设置simple基本上只会推送您当前的分支到其上游远程对端。远程由分支机构的branch.<remote>.remote设置确定，否则默认为原始存储库。
在Git 2.0版之前，默认设置matching基本上只是将您的所有本地分支推送到遥控器上具有相同名称的分支（默认为起源）。

您可以通过阅读更多push.default设置阅读git help config或在线版本的git-config（1）手册页。

用--force-with-lease强制更安全地推送


通过“租赁”强制地推送如果在远程上有意料之外的新提交（从技术上讲，如果尚未将其提取到远程跟踪分支中），则允许强制推送失败。如果您不想意外地将其提交，这将很有用覆盖您甚至还不知道的其他人的提交，而您只想覆盖自己的提交：

git push <remote> <branch> --force-with-lease

您可以了解有关如何使用--force-with-lease的更多详细信息通过阅读以下任何内容：


git push文档
Git：如何忽略快进并将原点[分支]还原为较早的提交？

#3 楼

另一个选择（避免任何可能对其他贡献者造成问题的强制推送）是：


将新提交放入专用分支中
在master上重置origin/master
/>
将您的专用分支合并到master，始终保留来自专用分支的提交（这意味着在master的顶部创建新的修订版本，以反映您的专用分支）。
请参阅“ git命令使一个分支像另一个”来模拟git merge --strategy=theirs的策略。

这样，您就可以将master推送到远程，而不必强行执行任何操作。

#4 楼

git push -f有点破坏性，因为它会重置团队中其他任何人所做的任何远程更改。更安全的选择是{git push --force-with-lease}。{-force-with-lease}所做的就是拒绝更新分支，除非它是我们期望的状态。即没有人更新上游分支。在实践中，这是通过检查上游引用是否符合我们的预期来实现的，因为引用是散列，并且将父链隐式地编码为其值。
您可以确切地告诉{--force-with-lease}检查，但默认情况下将检查当前的远程引用。实际上，这意味着当Alice更新其分支并将其推送到远程存储库时，分支的ref指向头将被更新。现在，除非Bob从遥控器上拉出，否则他对遥控器的本地引用将是过时的。当他使用{--force-with-lease}进行推送时，git将对照新的远程服务器检查本地引用，并拒绝强制进行推送。 {--force-with-lease}仅在没有其他人在过渡期间将更改推到远程的情况下才有效地强制推入。系上安全带即可{--force}。

#5 楼

为我工作：

git push --set-upstream origin master -f

#6 楼

使用tortoisegit的简单步骤

GIT提交本地文件并推送到git存储库中。

步骤：

1）存储更改
存储名称

2）拉

3）存储弹出

4）提交
1个或多个文件并提供提交更改描述集作者和日期

5）推送