最近在一篇别的网页中看到一句话，大致内容是

除非只有自己一个人用，不然用 push --force 的都该去死

确实，git push -f表示将目前自己本机的代码库推送到远端，并覆盖，这回造成什么样的影响呢，我们来模拟进行一次操作

实验过程

1. 首先进行初始化一个代码库

https://github.com/happut/test_git_f
初始化一个远端库，并clone到a/b两个目录，用来模拟两个人的提交情况。

2.a进行修改，并提交一次commit到本地库中，并推送，之后本地目录树和服务器目录树分别如下

image.png image.png

sha-1值均为9abf12a

3.a继续修改，提交commit2

image.png image.png

commit2 sha-1值为6d86006

4.b进行git pull，a则对历史提交进行改写git commit --amend，提交commit2'

image.png
本地库的commit2的sha1码已经变成0dfe661

此时进行push，明显推送不上去

image.png

因为远端的库和本地库历史不一致，又无法fast-forwards。

好，那我们git push -f推送

image.png image.png

推送成功，远端库也该为0dfe661

那么这样修改后，对另外的开发者有什么影响呢

5. b进行git pull

image.png

这什么鬼，看看历史

image.png

自动生成了一个merge commit

结论

其实在推送时，尽量避免git push -f的操作，或者说git push -f是一个需要谨慎的操作，它是将本地历史覆盖到远端仓库的行为。

刚才的测试中，b开发者在a进行git push -f前已经进行git pull操作，所以历史上的commit2是可以查找到，但是如果没有任何其他开发者进行pull，a再改变历史并强制推送，这部分数据就会丢失。

当然也并非禁止，有时，如果代码组内review后，确认代码正确无误，保证大家未pull的情况下，强制推送后，可以保持目录树清洁。