[btilly]

What went wrong was multiple teams on unsynchronized 2 week schedules, and a culture that said that we had to accept the force push when other teams released.

So we released at the end of our cycle. It gets used for, if a vague memory serves, end of months billing. Meanwhile someone on another team "merged" our code, and actually randomly dropped a big chunk of our work. A week later they release. Some (but not all) of our features disappear. We pull that and don't notice because we're on a new sprint. Wait until the end of the month, users try to do billing. "Hey, why did you take away those features you built for us a month ago?" "What, we never...?"

We had no clue what happened.

This got to repeat a couple of times before we figured out what must be happening. We made changes to the release process so we could track what was actually released each time, with its history. We tracked down who we thought was making the mistake, but didn't have enough evidence to prove it to his manager. That didn't stop the idiot from making the mistake, but it did streamline the process of recovering it. Meaning we had the version with our feature, we had current code, and "just" had to sort out conflicts rather than rewrite from scratch.

Now that you've heard the story, can you see how weeks of work could be lost before we figured it out? And can you understand how we could have lost history?

This was a decade ago. At my next job we had more competent people. But there we had a huge debates between rebase and merge people. There are arguments on both sides. My conclusion was that about 90% of the time, rebase makes things simpler and easier. But that remaining 10% of the time makes the 90% not worth it.

Just learn how to merge properly.

[doix]

I'm pretty sure your code was still around at that point, by default git keeps stuff around for 90 days. Although to be fair I don't know if that's the case today nor if it was the case a decade ago.

What you're describing does sound awful, but I'm pretty sure that idiot could have found a way to mess up a merge. The entire workflow sounds completely fucked, I'm not convinced it's entirely fair to blame rebase in that case.

> Just learn how to merge properly.

I know how to merge and rebase properly. My favorite PR merge strategy is rebase + merge --no-ff. So your master branch is nice and linear, but you can still see where your PR merges came in. Let's you have a "all PRs get squashed" view of the world by just adding '--first-parent' to your git commands, but also lets you have the inner details for when you're git bisecting or spelunking trying to figure out why a certain line exists.

Most people hate what I describe though, similar to mixing spaces and tabs.

[btilly]

My code may have been around somewhere. I suspect I'd done gc, in which case it wasn't. But my git skills then were certainly not as good as they are now. (I'd only recently switched from svn at that point.)

I agree that the workflow was a mess in multiple ways. A lot of which were organizational decisions that I was in no position to influence.

Your favorite PR strategy is fine if you're doing it locally. However when it is done on master, you're going to have to get master again by force. Because changed history creates conflicts. Which means that you're going to have to hope that everyone only did it your way, and no idiot created conflicts in some other stupid way that you'll suffer for later.

I'd prefer to merge to head early. Merge to head often. Merge from head often. Don't have long-running shared branches. This does take some other forms of discipline though.

[doix]

I've never worked anywhere on master directly. Always in feature branches that then get merged to master (ideally with my strategy). So basically master always moves forward and it's history is never rewritten.

Master is always locked down anyway by "something" - no idea what the technical term for Github/Gitlab/Bitbucket is. Stopping people from force pushing to master prevents the sort of stuff that happened to you. Even if you don't have any "idiots", you really don't want a poor intern accidentally slightly pissing off everyone.

> I'd prefer to merge to head early. Merge to head often. Merge from head often. Don't have long-running shared branches. This does take some other forms of discipline though.

I agree with everything there, except I rebase instead of merge. So when I merge my branch to master, it's a nice neat little package that sits on top of master. It doesn't have the history of 10 merges I did while I was developing because I don't see the value in those merges.

But hey, to each their own. When I was younger, I used to get into heated debates about why I was right, now I don't really care. I'm either in a branch of my own and can do whatever I want, or working with someone and then I'll just copy whatever they do to not confuse them.

[btilly]

Unless the strategy is really bad, I'd prefer to go along with what everyone else does. When multiple people push their preferred optimum, the resulting inconsistency is clearly worse than a single suboptimal, but consistent, approach.