我知道在Git中push --force是不好的做法。我的理解是push --force-with-lease是安全的。
考虑到这一点，我有一个关于三种变体的问题。
- 在一个分支上
push --force-with-lease是不好的做法，只有我添加提交，并且没有合并请求打开? - 是不好的做法，如果有一个合并请求打开的分支?
- 这是不好的做法，如果我知道有人把它在本地审查?
如果是，请说明原因。如果是这样的话，使这种做法成为一种糟糕做法的实际含义是什么?
在我看来，如果每个人都清楚只有我推到分支，它对其他人的唯一区别是，在git fetch origin my-branch和git checkout my-branch之后，他们必须git reset --hard origin/my-branch而不是git merge，这稍微长一点。
如果有的话，我错过了什么拼图?
人们通常不建议强制推进的原因是，对于许多分支，特别是存储库中的主要分支，人们希望更新分支总是快速前进的合并。
如果你只是在分支上工作，那么无论你是否使用--force-with-lease，都不会有强制推进的问题，因为你没有修改任何人的期望。没有人会因为你那样做而变得更糟。
如果你决定强行推进，这是一个沟通期望的问题。如果你有一个打开的合并请求，那么有时当你强行推进时，人们很难重新审查，所以你可能希望避免它。在这种情况下，我通常做的是用git commit --fixup或git commit --squash添加修复或压缩提交，然后，在审稿人批准后，压缩它们。
无论如何，如果你与你的团队成员或其他贡献者进行有效的沟通，并让他们知道你是在强制推动，那么问题就不会那么严重。在一个开源项目中，你不能总是有这样的交流，那么最好尽可能避免它。
git push --force-with-lease更安全，你也有git push --force-if-includes(Git 2.30+)，它试图确保被强制推送的内容是在检查即将被强制替换的远程ref尖端的提交之后创建的。
但在这两个例子中，这都是一个沟通问题。
(团队成员之间的沟通是这里缺失的主要部分)
我在合并MR时遵循的规则是，如果合并不是快进的，就拒绝。
这意味着在重新申请要合并的MR之前，被请求者必须在新的目标分支HEAD之上重新设置MR分支。
当然，如果我强制推送到作为MR源的分支(而不是目标)，则没有问题，MR将自动更新。