Why would I want to do git rebase?

Question

I've seen lots of people talk about git rebase and what it does, e.g. Hg: How to do a rebase like git's rebase and people talk about what it achieves (gives linear history), e.g. here Git rebase loses history, then why rebase? But I can't fathom why you would want to do this.

It seems like a big expense, to go back and revise your commit history (which must surely involve some ugly merges with n-way conflicts). And I could imagine cases where it could be very misleading, (e.g. if two people solve the same problem in different ways, but the history doesn't show their work as having occurred in parallel; seems that could easily lead to criticism and resentment too in some high-pressure coding environments).

What you gain is an easier to understand, but incorrect, history graph. What makes that worth the effort?

Thanks in advance.

Answer 1

Rebase is most useful when pushing a single commit or a small number of commits developed in a short time frame (hours or minutes).

Before pushing to a shared server, one must first pull the commits made to the origin's HEAD in the meantime—failing to do so would create a non-fast-forward push. In doing so, one can choose between a merge (git pull) or a rebase (git pull --rebase) operation. The merge option, while technically more appealing, creates an additional merge commit. For a small commit, the appearance of two commits per change actually makes the history less readable because the merge operation distracts from the commit's message.

In a typical shared development tree, every developer ends up pushing to a shared branch by doing some variation of git pull; <resolve conflicts>; git push. If they are using git pull without --rebase, what happens is that almost every commit ends up being accompanied by a merge commit, even though no parallel development was really going on. This creates an intertwined history from what is in reality a linear sequence of commits. For this reason, git pull --rebase is a better option for small changes resulting from short development, while a merge is reserved for integration of long-lived feature branches.

All this applies to rebasing local commits, or rebasing a short-lived feature branch shared by closely connected coworkers (sitting in the same room). Once a commit is pushed to a branch regularly followed by by others, it should never be rebased.

Answer 2

TLDR: Rebase strategy is not worth the effort.

The only benefit of rebase strategy is linear history and that's it.

Now ask yourself a question how many times you have checked git history to figure out something? Would you be able to solve it with a merge strategy?

My answer is almost never and yes merge strategy is not great but good enough.

But here comes the cost of rebasing strategy:

• you have to rebase your changes each time someone else pushes changes to the main branch, it is fine for 3 devs but for more, it becomes a problem, add to it waiting for a pipeline to build and it becomes a horror to merge anything.
• you can only "merge" one change at a time to the main branch all others has to be rebased first and build by pipeline again (extra delay).
• resolving conflict has to be done for each commit separately, resolving conflicts for older/outdated commits is insane to me if I know that I have changed it in the next commit.
• if you mess up rebase you would add all the fixes to the last commit and all the older ones would stay broken. The alternative is to start everything all over again.
• you have to force push to your branch after rebase, if you mess it up you may spend long hours scanning reflog.
• if you have more than two commits on your branch you likely squash them before rebase to have less work and you lose your precious commit history.

I have tried both and when I compare benefits with downsides the Rebase strategy is not worth an effort.

Answer 3

Performing a rebase usually involves no more conflict resolution than a merge, so the expense compared to that is minimal (just the time it takes to replay your commits, really).

As with most things related to git, you should only rebase if you know what you're doing, and why you're doing it. Here are some of my reasons for rebasing:

• I've worked on a patch series that hasn't touched any components that have been altered upstream in the meantime. A merge commit wouldn't contain any useful information in this case.
• I'm about to submit a pull request on GitHub, and the merge commit required would be a lot of work. By rebasing first, I make the pull request easier for the upstream owner to handle. Certainly I could merge instead, but as they've never seen my code before, that will just make the patch series harder to read.
• I'm merging changes in from upstream, and there are a large number of conflicts. git rebase lets me resolve these conflicts on commit at a time, making it easier to understand, and test as I go. If I care about maintaining a merge commit, I can just go back afterwards to a non-rebased version of the branch, merge it with upstream, then use the diff against the rebased version as the conflict resolving merge commit.