I had a colleague (smart guy, lots of impressive Ivy League creds after his name) who just _insisted_ that rebasing was evil. There was simply no way to communicate that:
- I can rebase all I want in my own private repo
- Rebasing is fine if no one else thinks they can depend on your branch's history
- You obviously don't rebase master (!) or a branch that you'll collaborate on (not without proper warning at least).
I've seen this attitude more than a few times, and I think it's fear born of ignorance. I just don't get the inability to consider a different perspective.
As someone in the "merge-only" camp, for me it simply boils down to I don't think rebasing solves anything I view as a problem and as such I just don't care to know anything about it. You can rebase if you want, but don't bother trying to talk to me about it.
Not only ignorance. I don't generally use rebase myself. This is after having some experience with it. I recently had to help a junior un-wedge his local repo after an attempted rebase went haywire. I reset to the previous commit and replaced the rebase with a merge. The rest of the lifetime of the branch was uneventful. The problems happened because rebasing changes the identity of commits. When merging that result, commits that have previously been merged create conflicts as they now need to be re-merged under the alias of a different commit hash.
If rebasing works for you, I'm not going to try to sell you something. But there are other ways.
> The problems happened because rebasing changes the identity of commits. When merging that result, commits that have previously been merged create conflicts as they now need to be re-merged under the alias of a different commit hash.
And this literally cannot happen in the standard rebase workflow where you have one development branch and then rebase your feature branches on top of that development branch before (fast-forward) merging.
Smart people with strong opinions. What can you do.
I've come from a merge workflow into a rebase (git + gerrit) workflow in a huge software project with hundreds of people. Rebase workflows are fine. Merge workflows can be fine.
Personal preferences + the way you're used to doing things.
There's some advantages to being able to see how conflicts were resolved when you're looking for something that went wrong but if you have code reviews and tests then the probability of needing that in a rebase workflow is smaller. In a large team "how we got to a change" is IMO less interesting than "this is the change".
Have seen occasional breaks from things that were incorrectly rebased (generally from auto-rebase situations), but those are rare enough and easy to address. Same things can happen with merges.
An IMO much larger question is branching strategy. Normally if you're following a rebase workflow you're doing trunk based development. Many teams that use a merge workflow use feature branches. If you use feature branches you're pushed towards merge workflows. That's a bigger debate maybe (and I'd vote for trunk based).
> I had a colleague (smart guy, lots of impressive Ivy League creds after his name) who just _insisted_ that rebasing was evil.
There is an historical reason for this. It is a hyperbolic marketing point of view invented by Richard Hipp, the author of SQLite, and of Fossil, in order to try to sell Fossil as being superior to Git. “Rebase is a lie” has been a meme ever since he published an article titled “Rebase Considered Harmful”, which has been posted to HN many times. Because he has contributed a lot to open source software development and because SQLite is so widely used, a lot of people respect everything he says and so this unfortunate idea has spread and gets repeated, even by otherwise very smart people.
Dr. Hipp has made appearances on HN arguing that rebase is bad, and even told me it should be likened to criminal activity. (https://news.ycombinator.com/item?id=29133188) The Fossil documentation still has remnants of it, but it has been softened over the years.
Luckily it seems to be dying, and I think the Fossil team might be coming around to the realization that this negative attack smear hyperbole is ultimately not helping Fossil grow. This is the primary sticking point for me and the reason I won’t use Fossil. I’m actually quite interested in trying it, but not until the (ironically) dishonest claims about Git and it’s goals are taken down.
>[From the linked HN comment] To erase an entry in the financial ledger of a company is fraud. It is a felony. [..] I believe that VCSes should be treated similarly. [..] once you check-in the change - it then becomes part of the permanent record. To alter that transaction after the fact is akin to felony fraud.
Yikes. To give a charitable interpretation, that's quite an extreme view. Financial ledgers and VCS histories are not equal and they serve different purposes; the primary purpose of VCS history being to aid in the understanding of the current state of the codebase. In some cases, the "true" activity may provide that understanding, and in others, it may hinder it. Squashing a PR-requested change like "rename new variable based on PR feedback" seems sensible as it reduces noise in the history - definitely not what I'd call fraudulent. To me commits are like documentation and I see no reason why I shouldn't be able to refine that documentation if I think I can improve it for a future reader.
There’s no such thing as false history in git. Git was not designed to provide an audit trail of keystrokes, and as you can see from the larger comment thread here: nobody needs that. Git provides a mechanism for establishing and rearranging commit dependencies. The order of commit dependencies can be changed by design.
You are factually incorrect about rebase making things harder for people or tools to understand. The primary use case for rebase is making things easy to understand, in private branches after liberal use of the ‘commit early; commit often’ rule. If you take rebase away from git, and ask people to be okay with commits becoming immediately permanent, you increase the chances that people will make mistakes or lose work before they commit, and you remove some flexibility of being able to work on multiple separate topics in a single branch. Like any and all tools, rebase can be used incorrectly, but it is not used incorrectly most of the time, and basing your argument on the rare accidents means the argument is straw man.
- I can rebase all I want in my own private repo
- Rebasing is fine if no one else thinks they can depend on your branch's history
- You obviously don't rebase master (!) or a branch that you'll collaborate on (not without proper warning at least).
I've seen this attitude more than a few times, and I think it's fear born of ignorance. I just don't get the inability to consider a different perspective.
Edit: formatting.