
How you can go wrong with Git - adityasridhar
https://adityasridhar.com/posts/how-you-can-go-wrong-with-git
======
justushamalaine
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.

------
saagarjha
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.

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

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

------
black-tea
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).

------
jamietanna
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/](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`

------
singularity2001
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).

