仅本人维护的Git分支能否执行force-with-lease强制推送？

首先明确两个强制推送的核心差异：

• git push --force 会无条件覆盖远端分支的所有提交，不管远端是否存在你本地没有同步的内容，极易误删他人提交，除非你100%确认分支状态，否则任何场景都不推荐用。
• git push --force-with-lease 带基础保护逻辑：只有当远端分支的当前提交哈希，和你本地记录的远端追踪分支哈希完全一致时，才会执行覆盖，本质是“我确认我上次拉取之后没人往这个分支推新代码，才允许我覆盖远端”，能避免绝大多数误覆盖问题，但它解决不了“修改分支历史给其他协作者造成困扰”的问题。

三个场景的判断结论 #

1. 仅本人提交、未创建MR的个人专属分支 #

完全不属于不良实践，属于常规操作。
这类分支本质是你的个人工作区，没有对外协作、没有绑定评审流程，你完全可以自由修改提交历史：比如本地rebase到最新主分支、合并零碎的调试提交、修改错误的提交信息，普通push因为历史不一致被拒绝时，用push --force-with-lease是最安全的选择。它的保护机制还能兜底防止你记错分支名、误往公共分支/他人分支做强推的低级错误。

2. 已创建开放状态MR的分支 #

不属于绝对的不良实践，但要根据评审阶段判断是否合适。
如果你们团队约定MR对应的功能分支仅由提交者本人推送，其他协作者只会在MR页面做评论、不会直接往分支推代码，那么在评审初期（还没产生大量行级评论时），你为了整理提交历史、rebase主分支解决冲突使用push --force-with-lease是完全可接受的，也是很普遍的开发习惯。
但如果MR已经进入评审中后期，评审人已经留下了大量绑定到具体代码行的评论，就不建议再强推了：提交哈希变更后，旧的行级评论会丢失锚点，变成脱离代码上下文的无效评论，平白增加评审人的沟通成本。这种情况建议先追加修复提交，等MR通过、准备合并前再统一整理提交历史即可。
如果你们团队有多人共同往同一个MR分支推代码的协作习惯，强推前必须先执行git fetch确认分支最新状态，虽然--force-with-lease会在有他人新提交时自动拒绝推送，但提前同步能避免反复推送失败的问题。

3. 明确知晓已有协作者拉取分支到本地开展评审/调试的场景 #

属于不良实践，除非你提前同步了所有相关人员。
你之前的认知存在明显遗漏：“协作者只需要执行git reset --hard origin/my-branch就能同步”的前提，是协作者在本地这个分支上没有做任何独立提交、没有基于这个分支拉取新的本地分支做测试/修改。
实际协作中会出现很多你预料外的问题：

• 协作者可能根本不知道你强推了分支，后续执行git pull时会遇到无意义的合并冲突，甚至不小心把旧的历史提交重新合并回远端，把整个分支的历史搞乱
• 协作者拉取分支后可能在本地写了调试代码、做了临时验证提交，甚至直接帮你写了修复代码准备推到分支上，你强推后他本地的提交会和远端历史分叉，要找回自己的改动需要做cherry-pick等额外操作，稍有不慎就会丢失本地工作成果
• 协作者如果基于你的分支拉取了测试分支、预发布验证分支，你修改原分支历史后，这些衍生分支的提交链会断裂，后续排查问题、对版本的时候会出现提交记录对不上的问题

容易被忽略的注意事项 #

• --force-with-lease不是强推的“免死金牌”，它只能防止你误覆盖远端最新提交，完全解决不了修改分支历史给其他协作者带来的协作成本，不要因为它更安全就随便在共享分支上改历史。
• 如果确实需要在有协作者使用的分支上强推，必须提前在对应的沟通渠道（MR评论区、团队群）明确通知所有人强推的时间，以及后续同步分支的正确操作，推完后最好再次提醒相关人员同步。
• 任何已经合入主干、发布分支、生产环境分支的提交，绝对不要用任何形式的强制推送修改历史，这类公共分支的历史一旦被篡改，会影响所有团队成员的本地仓库状态，甚至会导致版本发布、线上回滚流程出问题。
• 强推前一定要确认本地分支是基于最新的远端代码做的修改，避免因为本地太久没同步代码，触发--force-with-lease的拒绝逻辑，做无意义的重复操作。

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