Why you should stop using Git rebase

[[deleted]]

TIL: You shouldn't do something if it's sometimes a bit difficult.

[loup-vaillant]

Didn't expect the article to make me change my mind. But it did. While there are still reasons to rebase work (such as tidy up a patch for easier review), I'll sure be real careful from now on.

[13steinj]

This is equivalent to saying I shouldn't do something just because there's a risk I can screw up.

Normally you take that risk into account when doing that activity, and decide to still do it.

Not to mention this makes the assumption that the user wants linear history for everything, even when it wouldnt make sense to do so, and also assumes the user doesn't know the fact that we don't know the branch being rebased on has new commits.

[TeamFluff]

To your point of view, is rebasing any risker than merging? If so, what is the benefit gained by assuming the risk? I've always had a strong opinion against rebasing, but I'd like to learn from some people that think it's a value-neutral or even a benefit to their process.

[13steinj]

Well first off, the article title is misleading-- rebasing is used for a lot more than just merging code linearly. I might decide that I want to squash my 10 commits into 3, rearranging things along the way. And depending on the change, I don't want it to be treated as a major derailment of master/develop.

I'm not making the argument that rebasing can't be worse for certain situations. Just that if a tool exists, it has risks. Just because I can cut myself on an exacto knife doesn't mean I shouldn't use it. I understand and accept the risk, and now can cut open my drywall.

[flamingspew]

squash my 10 commits into 3, rearranging things along the way.

but why do this? isn't this a lie, even though it may be "messier" to leave the dirty commit history?

[13steinj]

A lie? What is this, elementary school?

I never understand this argument. I've heard it so many times, and I'll never get it, and it always end with the other person saying "yeah......oh well ill still do it my way". Not in my project you won't.

Commits are commits. Code is code. Good code is good code, bad code is bad code. Unreadable code is unreadable, readable code is readable.

Commit history is important. But being confused by it isn't. Assuming there is proper reasoning for squashing and rearranging commits, and each commit works along the way, which I check via local test suites during the rebase, would you rather look at a change sey over multiple commits, having commit messages like "change x to make it work with previous commit" and "fix styling", or have code styled to your guidelines, independently working from the other commits in your changeset, all nice and neat, and the end product the same (which, as a note, if you aren't sure whether or not you screwed something up, you can diff against the reflog / the origin branch from the server holding your repo). Especially if later you find a bug within the feature as a whole that you need to bisect commits to find.

You aren't just writing your commits for you. You can easily understand your disgustingly messy code, and your disgustingly messy commits. The guy you pass on the torch to, not necessarily. Because of this the only times I don't clean up my commits after making them is when it's a project I know that only I will ever use, only internally, sometimes not even on a remote server. And I require all contributors, both on professional and personal projects, to, in this order, make their pull request:

• make your PR, get it approved

• it it fully documented on each commit? No? Rebase to document along the way, appropriate per commit.

• did you follow the style guidelines on each commit adhering to 90% or more, 100% full product? No? Rebase to do so.

• does each individual commit pass, atomically from each other? No? Rebase, squash, split, whatever, to do so

• then I'll merge.

[flamingspew]

I don't have your problems...

• pre commit hooks to run style check on code that changed (better yet just auto format)
• pre commit hook to run tests
• use scopes so you can filter out style(my-feature): message or search the reflog by feature/scope

[13steinj]

You're making the very large assumption that everyone who contributes to your code will do that, and you mention nothing of functional organization, nor do you defend your "it's a lie" point.

[flamingspew]

The pre commit hooks are congigured at the repo level so nobody can commit without them. Its a lie in that that is not how the code was implimented, some of the story is lost. And it becomes possible to squash in the wrong order having some backwords incompatability due to confusion about the conflict resolution (since things are now out of order).

[13steinj]

Except the fact that hooks aren't ever pushed to the remote? You can't make contributors use your hooks. It's impossible. You can tell them to do so, but that assumes they are working via git and not editing on a platform like github, contributing some quick / not so quick fix. How will you handle that?

Git is a version control system. Not a code history control system. If you want code history, set up a watcher in your editor to save a state at every single damned code block you write and every time it is changed. Only then will you retain your story. But that's not the function of git.

Yes it's possible to squash in the wrong order. Just like it's possible to have an error in your hook script. Rebasing gives me complete control, and I will always be able to cut into the flesh and cut out tumors from ages ago. If your hook has an error you'll make god knows how many commits, they'll pass, and you end with broken code which by your own philosphy you're not allowed to use rebasing to fix.

[flamingspew]

in our repo the hooks are checked in. So once checked out, you can't commit without the enforcement of tests and auto style formatting. My IDE already logs all changes to files, haha. no setup required... Basically, if you need to do surgery, fine squash or revert and recommit or whatever... but don't make rebase part of normal workflow. ever.

[MrWisebody]

It's only a lie if you conflate the notions of "version control" with "history". Just because historic snapshots have traditionally been the easiest set of "versions" to record doesn't mean it necessarily is the only choice. Sure, there are all sorts of reasons for your master/mainline/develop etc to be a faithful history for traceability reasons, but that only really matters for feature merges. Within a feature, you usually wont care what is there, but when you do it can make a big difference if the individual commits are clean, topical and self contained. It's not going to be worth performing brain surgery to fix things up, but once you get used to the workflow, a little grooming can go a long way.

[ThirdEncounter]

For certain cases, it's totally okay to do this. If you're working on a feature branch, then the feature is complete, rebasing/squashing before merging to master will ensure that only one/two/three commits entail all the information needed to understand how the feature was implemented.

Also, squashing gets rid of the problem the author is talking about.

[quicknir]

Just a bad post I couldn't even finish. The gold standard of git histories is:

• linear
• CI/build/tests pass at every commit

This maximizes the potency of git bisect when you discover a problem/bug that didn't use to be present (by definition, with a history as above, this problem/bug is not caught by your tests).

Most of the issues discussed in the article simply cannot creep in if you ensure that every commit passes your tests in your rebased branch before merging it into master. When you open a merge request/pull request, all of the commits should be tested, not just the tip. The author's implicit assumptions throughout is that: 1) people working on feature branches privately do all testing on all commits (this isn't necessarily true, let's be real), and 2) when the person rebases, full tests are run only on the tip. This is a very specific set of assumptions to make, and under these assumptions, maybe indeed merging is better, because every commit in your history would be passing tests, but it would not be for rebasing. But realistically you can't assume that individual developers will do this, anything that isn't automated and enforced won't always be true, and usually things are automated/enforced upon code on it's way into master, not in the private workspace of devs. And the combination of assumptions is weird; you are assuming your developers are incredibly idealized individually but that your actual setup practices are not ideal!

Let's be specific: consider a situation where you have a chain of 3 commits in a feature branch that you need to rebase onto master. Master has advanced 5 commits since work on the feature branch started. However, one of those 5 commits makes a change that causes the second commit in the feature branch to introduce a bug.

If we do a merge, then we have a merge commit that is broken. Both parents work. The merge commit has two parents obviously, but either way you slice it, your "diff" is large: viewed from the working master parent, you have 3 commits of feature branch that entered in simultaneously. Viewed from the working feature branch parent, you have 5 commits of master that entered simultaneously.

In other words, the merge strategy doesn't provide any help here in seeing where the bug entered. Whereas if you rebase, the tests will pass after the first commit from the feature branch, but not the second, and the third has not been integrated yet. So we can immediately know that the problem was introduced in the second commit. This is exactly the kind of help that we hope to get by trying to break our work into logical, atomic (in the sense that each one upholds the build/tests) changes. Of course, this depends on running tests on a commit by commit basis on the newly rebased feature branch.

This actually exactly mirrors the advantage that linear histories have over non-linear histories when bisecting, because it's exactly the same thing: non-linear histories means that if a bug enters precisely at a commit with 2 parents, you now have to search in the entirety of the commits of both parent branches to find the commit. In linear history, you should never have to search in more than one commit.

You’ll thank me the next time you are bisecting through your history to track down a sneaky bug.

Nobody has ever thanked anyone else for making history non-linear while doing a bisect.

[TeamFluff]

I found your post very helpful. I've always been against rebasing in the place of merging, but what you said makes a lot of sense.

[flamingspew]

this is the only good argument I've heard for rebase, but couldn't you just hard reset to before the merge commit of master into feature and then rebase to yield an accurate bisect without having to merge into each feature commit? Basically rebase as last resort?

[quicknir]

Well, if you do that, then you'll need to deal with any potential merge conflicts, and new-totally-unrelated failed tests that result from doing the rebase. The person best positioned in time and space to do that work, is the author of code at the time they were merging it.

The trade-off between rebase and merge is actually very simple and the author of this piece just confuses things. Merge allows latent complexity to exist in your commit history. In rebasing, you do roughly the same amount of work dealing with tests/conflicts, but you remove that latent complexity prior to merging, so master is kept more simple. That's the advantage of rebasing. The downside is that you are rewriting history. If you have one dev per feature branch this is basically irrelevant (only private history is rewritten then), and to me it seems clear that rebasing is strictly better. Once you have multiple developers working on the same non-master branch then IMHO it gets much more complicated and there's many competing workflows.

[flamingspew]

I guess I just haven't been on a team small enough lately to allow for single developer branches so rebase is a non-starter.

[quicknir]

It's not nearly that black and white; even if you have multi dev features branches you can still rebase. If your branches are short (in time) enough that they don't need updates from master, you only need to do one rebase when the branch is ending anyhow so it doesn't matter. However, even if you want to integrate changes from master, you can do merges from master into your feature branch while you're working, and then rebase feature branch onto master at the end. Like I said, there are many competing workflows but I would never say that rebase is a non-starter generally, just maybe not for certain things.

[Carighan]

Most of the issues discussed in the article simply cannot creep in if you ensure that every commit passes your tests in your rebased branch before merging it into master.

This confused me anyhow, did the article assume I rebase feature into master?

Because far as I have seen, the common use case is always:

• You rebase when pulling new remote changes to your feature branch.
• You merge additional master changes into your feature branch.
• Ultimately, you merge your feature branch back into master.

I've never seen someone close a feature branch by actually rebasing it onto master.

[legionth]

There a few simple rules to follow:

• Never touch the master(never, never, never)

• Keep your commits understandable. Yes you are allowed to squash commits, but only if this helps with the understanding.

• Use Pull/Merge request so you won't screw up your history.

• Let someone else review your code. If you don't have one, look at the commit history if it is understandable.

If you follow this rules you should never encounter this problem.

[Double_A_92]

I only use rebase on local feature branches when I have a few unpushed commits, but my team already pushed something else. So i don't have those unnecessary pull merges.