独立开发项目时使用git push --force是否存在风险？

哪怕是完全没有协作者、100%由你自己独立维护的项目，使用git push --force依然存在明确的可落地风险，并非操作上绝对安全的选择。这类风险的来源和团队协作场景有明显区别，但实际造成的后果可能更严重：

• 多本地副本的交叉覆盖风险
  多数独立开发者不会只在单台设备上维护仓库：常见场景包括台式机做主力开发、笔记本临时同步改动排查问题、甚至在云服务器上拉取仓库做临时测试。如果在设备A上重写了提交历史（比如squash提交、变基整理提交记录）并force push到远端，后续在设备B上操作时，若没有重新拉取最新的远端状态就再次执行force push，会直接把设备A已经推到远端的有效提交覆盖丢失。这类场景在跨设备同步的独立项目中非常高发，毕竟没有协作者帮你校验提交内容的完整性。
• 本地状态过期导致的不可逆提交丢失
  git push --force的本质是用本地的提交历史直接替换远端分支的现有历史。如果某次执行force push时，你本地的仓库版本已经落后于远端（比如你忘了自己3天前在另一台设备上推了几个提交到远端，这次本地是更早的旧版本），直接force push会把远端上后来新增的提交全部覆盖。这类丢失的提交因为没有其他协作者的本地副本留存，仅能靠你自己本地的reflog找回，一旦超过reflog默认的90天留存周期，提交内容就会永久丢失。
• 操作误触的兜底缺失风险
  团队协作场景下的分支保护、提交校验机制在独立项目中往往被完全省略——很多独立开发者不会给自己的个人项目配置分支保护规则，也没有人做合并前的交叉检查。一旦出现手滑选错目标分支、配错remote地址的情况，force push的操作会直接覆盖掉正式分支上的历史，没有第二层校验机制帮你拦截误操作，后续的恢复成本完全由自己承担。

实际使用建议：哪怕是独立开发，也尽量用git push --force-with-lease替代git push --force。这个命令会先校验远端分支的当前引用是否和你本地最后一次拉取时看到的引用一致，只有状态匹配时才允许执行force push，能从操作逻辑上拦截大部分跨设备同步、版本过期导致的误覆盖问题。
如果你确实是单设备维护的极简项目，平时从来不会跨设备同步代码，那force push的风险会大幅降低，但依然不建议养成无条件用--force的习惯，因为项目规模变大后难免出现跨设备操作的场景。

内容的提问来源于stack exchange，提问作者YulePale