Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why would I want to do git rebase?

Tags:

git

git-rebase

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.

like image 443
hcarver Avatar asked Nov 02 '12 10:11

hcarver


People also ask

When should you use Git rebase?

Use rebase to catch up with the commits on another branch as you work with a local feature branch. This is especially useful when working in long-running feature branches to check how your changes work with the latest updates on the master branch.

Why you should avoid Git rebase?

Case 1: We should not do Rebase on branch that is public, i.e. if you are not alone working on that branch and branch exists locally as well as remotely rebasing is not a good choice on such branches and it can cause bubble commits.

Is it better to pull or rebase?

It is best practice to always rebase your local commits when you pull before pushing them. As nobody knows your commits yet, nobody will be confused when they are rebased but the additional commit of a merge would be unnecessarily confusing.

Should I use Git merge or rebase?

For individuals, rebasing makes a lot of sense. If you want to see the history completely same as it happened, you should use merge. Merge preserves history whereas rebase rewrites it . Rebasing is better to streamline a complex history, you are able to change the commit history by interactive rebase.


3 Answers

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.

like image 79
user4815162342 Avatar answered Oct 18 '22 00:10

user4815162342


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.
like image 25
jbowes Avatar answered Oct 17 '22 23:10

jbowes


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.

like image 1
Dariusz Bacinski Avatar answered Oct 17 '22 23:10

Dariusz Bacinski