There is this fun way of not nuking others changes in the remote `git push --force-with-lease`.

This pushes your commits if you already know all commits that are in the branch in the remote. Of course this still leaves the problem that others will have merge conflicts when they pull from the remote.

Rebasing is powerful tool and it really provides great benefits.

Especially before your merge your branch to master. It is lot cleaner if someone cleans the branch history so that commits are combined to clean nice commits, before it is merged to master.

Personally I am annoyed about `fix typo in last commit` commits merged to master.

In summary: don't mess with your remote. Rebase, amend, go nuts on your local branch, it's fine. But don't forcibly rewrite history for other people. If you mess something up, add a commit fixing it; don't just nuke it.

Not quite. Just have at least one branch (like master) where everyone agrees to never ever rewrite history. Rewriting history on feature branches that are already pushed is very useful.

Unless you decide that your git history is not worth maintaining. In that case only merge and commit and never force push. But git history is worth the extra effort to learn to rebase properly imo.

and for god sake if you can avoid it, and you should, do not use git LFS.

What's so bad about git-lfs? (never used it)

Technically the code isn't lost after you do a force push, but it does cause some extra work.

You can disable force push on branches. It's probably a good idea for any branch that is shared. People sharing a branch need to coordinate and rebase their own branches locally. You can merge without any coordination, but it creates a messy history.

I have a rule where you never rebase during a code review, but you do rebase at the end. It's a pet peeve of mine when someone addresses my concerns by amending a commit. Please don't. Use a fixup commit so I can follow what you've done. Then at the end the maintainer should ask you to rebase before he merges it (do autosquash, then manual squashes etc, then base on master).

As another commented mentioned, `git push --force-with-lease` is a better way of doing this. But [as I recently wrote about](https://www.jvt.me/posts/2018/09/18/safely-force-git-push/), its safer to have a `ref` as well, ie `HEAD`, so you're instead running ie `git push --force-with-lease=HEAD`

While slightly different than the original complaint I hate how `git stash pop` handles conflicting files. Instead of creating file.orig file.remote ... as other commands do, it immediatly puts >>>> everywhere <<<<, leaving a mess if you are not careful (and commit/push/run broken code).