2

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?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
marcotama
  • 1,991
  • 2
  • 19
  • 24
  • 1
    Actually, force pushing to a feature branch on which _only_ you work is not bad practice at all. – Tim Biegeleisen Jun 08 '22 at 07:22
  • 1
    `--force-with-lease` is safe**r**, not safe - it's still not generally a good thing to do on a shared branch. – jonrsharpe Jun 08 '22 at 07:25
  • If you work in different repository copies, like one at home and another at work, or like one at `/path/to/foo` and another at `/path/to/bar`, it can be considered that two or more persons are maintaining the same branch. It's still possible you overwrite and lose your own data. It's okay if you know the consequences of force push. But it's not suggested to use it in any case even if you are the only maintainer. – ElpieKay Jun 08 '22 at 07:57
  • The way I like to put it is that for any branch name where you will use force-push, you *and all other users of this branch* must *agree* that force-pushes happen to this branch name. If you are the only user, you must agree with **yourself**. For most people, that's probably not too difficult or onerous. (Perhaps the multiple-personality types might have issues here. ) – torek Jun 08 '22 at 12:47
  • @jonrsharpe I could agree, depending on the meaning of shared branch. If I am the only writer and everyone else is a reader, do you consider that a shared branch? If so, why would you consider it not a good idea? It's the same issue I have with the golden rule of rebasing: https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing : what is a "public" branch? – marcotama Jun 09 '22 at 05:41

2 Answers2

2

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.

bk2204
  • 64,793
  • 6
  • 84
  • 100
1

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250