I don’t know git well, but I often run into the problem being discussed.

If I pull from origin before making my changes, I don’t have to merge, obviously.

But correct me if I’m wrong: I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched.

This is a common scenario for me. Correct some typos in comments for example, and I get forced to figure out how to merge using vim, which I don’t know how to use at all (being a nano user). I’m sure I could and should switch to at least using nano by default, but I don’t know how merging really works, either.

What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge.

> I don’t know git well, but I often run into the problem being discussed.

I do understand the problem being discussed; what I don't understand is what it has to do with pushing first. You have the same problem no matter which order you use `git push` vs `git pull`.

> I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched.

Yes, that's true.

> What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge.

You can do that with `git pull --rebase`, which, as others have mentioned, you can set as the default behavior of `git pull` like this:

https://news.ycombinator.com/item?id=27581416

Ooh, --force-with-lease looks like a nice feature, especially for updating github PRs that aren't yet merged. I still wouldn't want to use it where anybody else has a copy of the changes, since that's where you need a merge commit to avoid breaking somebody else's repo, but that gives me a safer option than a blind --force.

Just remember that --force-with-lease only protects you from overriding commits you have not yet fetched.