[thibaut_barrere]

PSA: I’m not terrified of rebase, yet it’s good to know this:

https://docs.github.com/en/get-started/using-git/about-git-r...

> Warning - Because changing your commit history can make things difficult for everyone else using the repository, it's considered bad practice to rebase commits when you've already pushed to a repository.

A similar warning is in Atlassian docs.

[ongy]

I think a large part of this is about how a branch is expected to be used.

Branches that people are expected to track (i.e. pull from or merge into their regularly) should never rebase/force-push.

Branches that are short-lived or only exist to represent some state can do so quite often.

[xlii]

Also branches that are write-only by a single person by consensus. E.g. "personal" PR branches that are not supposed to be modified by anyone but owner.

[thibaut_barrere]

It is this, plus more:

- the web tooling must react properly to this (as GH does mostly)

- comments done at the commit level are complicated to track

- and given the reach of tools like GH, people shooting their own foot with this is (even experienced ones) most likely generate a decent level of support for these tools teams

[mr_mitm]

Is there a reason why that recommendation cannot be changed to "don't ever force push unless you are certain no one else has fetched this branch"?

[z3dd]

Well that's a distinction which makes sense in theory but is not realistic in practice for most projects with multiple contributors.

[eichin]

"fetched this branch" needs to include "started reviewing the PR", and probably other cases; it does mean switching modes for devs who usually rebase privately.