I know in Git it's bad practice to push --force. My understanding is that push --force-with-lease is safe.

With that in mind, I have a question with three variants.

1. Is it bad practice to push --force-with-lease on a branch on which only I add commits and for which there is no Merge Request open?
2. Is it bad practice if there is a Merge Request open for the branch?
3. Is it bad practice if I know someone pulled it to review it locally?

If yes, could you please argument why? What are the practical implications that make this a bad practice, if they do?

In my mind, if it's clear to everyone that only I push to the branch, the only difference it makes to everybody else is that, after git fetch origin my-branch and git checkout my-branch, they have to git reset --hard origin/my-branch instead of git merge, which is slightly longer.

What pieces of the puzzle am I missing, if any?

CodePudding user response：

The reason people generally recommend against force pushing is because for many branches, especially the main branches in a repository, people expect updating the branch to always be a fast-forward merge.

If only you are working on the branch, then there's no problem with force-pushing, whether you do it with --force-with-lease or not, because you're not modifying anyone's expectations. Nobody else is worse off because you did that.

If you do decide to force-push, it's a matter of communicating expectations. If you have a merge request open, then sometimes it can be hard for people to re-review when you've force pushed, and so you may wish to avoid it. What I typically do in such a case is to add fixup or squash commits with git commit --fixup or git commit --squash and then, after the reviewer has approved, squash them down.

Regardless, if you communicate effectively with your teammmates or other contributors and let them know that you've force-pushed, then it's likely to be less of a problem. In an open-source project where you can't always have that communication, then it typically is better to avoid it when possible.

CodePudding user response：

git push --force-with-lease is safer, and you also have git push --force-if-includes (Git 2.30 ), which attempts to ensure that what is being force-pushed was created after examining the commit at the tip of the remote ref that is about to be force-replaced.

But in both instance, this is a communication issue.
(communication between team members being the main piece missing here)

The rule I follow for merging an MR is to reject it if the merge is not a fast-forward one.
Which means the requested must rebase the MR branch on top of the new target branch HEAD before re-applying for the MR to be merged.

Of course, if I force push to a branch being the source of a MR (as opposed to the target), there is no problem, and the MR would be automatically updated.