Hard agree. Do whatever the heck you want locally, just try not to screw everybody else up when you push.

(From the guy who force-pushed on a personal project yesterday to resolve a situation with multiple remote heads - I am ashamed)

Yeah... You should never rewrite history of shared branches. You are just asking for trouble in that case.

We informally allowed whatever you wanted until you opened a pull request.

Sure, unless you bork your local repo enough you need help from a teammate getting your work into a PR.

Not to say that doesn't make for a good learning moment.

At some point, every junior is going to mangle something, and need a senior to sit them down and give them the git reflog talk. It's an inevitability, and should be embraced as a natural part of the evolution of a developer.

Haha. what's the git reflog talk? To be clear I know what reflog is, but what's "the talk"?

Probably just making them aware of it. But I can give a slightly longer spiel:

Commits in git are immutable. They're identified by their hash, so they have to be. What's more they have the hash of the previous commits so the whole chain back to the first commit can't be changed. You can only add new chains.

As a consequence, if your main branch points to commit abc123 and your feature branch points to commit def456 then it doesn't matter if you merge, cherry pick, rebase or dance the fandango, if you point those branches back to those commits, the branches must by necessity look identical to the way they looked before you did anything.

And you can find out where they used to point in the reflog.

I'm certainly aware of reflog and have (thankfully) only had occasion to use it once or twice that I can remember.

To my original comment - having to force-push in order to resolve heads - is there a "correct" way to do this that doesn't feel gross?

You're going to have to explain your problem in more detail than "resolve a situation with multiple remote heads".

To explain, I'll borrow the solution that I first saw in a Fog Creek presentation from ages ago ("DVCS University")...

Essentially, if you have more than one person making changes to the same piece of code, the method for resolving them is:

1) Pull - gets their changes

2) Merge - puts their changes together with yours and you can reorganize them at that point.

Note, this was done with Mercurial which doesn't have the concept of a stage, so Pull feels like it has a slightly different meaning when you look at it that way. One [suggestion][1] for Git if you want to achieve the same effect - getting a Fast-Forward at the end - is to Rebase, then Merge last.

Part of me knew this, I simply forgot and wanted to get out of this particular hole.

[suggestion]: https://www.atlassian.com/git/tutorials/rewriting-history/gi...

That's the start of a setup, but that's not enough information for me to figure out why you needed a force push.

I'm not going to demand you explain more, but if you want to explain more then I'll try to answer the question you had about whether there's a better method.

Also Pull is generally a shortcut for "Fetch then Merge", and just getting changes is Fetch.

Just the explanation of "no matter how bad you've fucked up your repo, as long as you haven't run 'git gc' or waited a few years, all you need to fix it is to find the commit hash from git reflog, git checkout that hash, and then git branch to give you an easily accessible reference to the commit". Followed by some pointers on how to efficiently dig through reflog.

It's pretty freeing to realize that it's basically impossible to lose committed code.

Or made a "fresh clone". I've had colleagues nuke a repo when it gets in to a "bad state", start over with `git clone`, repeat the work that git lost...