Hacker News Reader

Comment by gavingmiller | Hacker News Reader

The OP gives his own definition for rebase: git rebasing is taking all your local changes since the last push and put them ahead of other people’s changes regardless of the date you made the commit.

But fails to explain _why_ you'd want to do that. Can anyone fill in that why for me?

View on HN

My understanding is that it keeps the history cleaner at the expense of being "historically correct". It's cleaner because you have fewer merge commits, but less historically correct because it makes your commits look like they happened after the commits pulled in by rebase.

Personally, I use merge (with --no-ff) vs. rebase. The only time I actually use rebase is to squash a series of (unpushed!) commits on a feature branch, and I usually only do that if I went hog-wild, committing more than necessary while experimenting.

It keeps the upstream history cleaner at the expense of being locally historically correct. In my opinion the nice thing about having everyone rebase onto upstream is that when their changes get merged into upstream, upstream's history shows an accurate linear representation of when a piece of code was accepted into upstream, which to me is far more important than having an accurate local history.

Great point. One of the more confusing things about looking at the upstream logs when not using rebase is that they are (by default) in chronological order. It does seem like it would be more useful to have commits upstream show in the order they were merged in.

master on your local repo is a different reference to master at origin and master at other developers machines. By merging your master into origin/master instead of rebasing, you leave the history looking like multiple branches were merged together.

By rebasing onto origin/master instead of merging, you leave the history looking linear.

Ultimately it's about aesthetics, you don't gain anything by rebasing (when pulling) other than a cleaner history.

I'm not certain this is due to the particulars of the workflow of the team I was working with, but one of the benefits I saw of rebasing over regular merging was that rebasing let us resolve conflicts at the point of the commit in which they emerged, rather than in a merge commit at the end.

When I'm working on a branch and I want to pull changes from master into my branch so that I'm working on the latest code base I do

> git rebase master

What this does is that it temporarily reverts all my changes on this branch, applies all the changes from master on my branch and then reapplies my changes on this branch.

Something I wrote up nearly three years ago that should explain rebase vs merge

http://gitguru.com/2009/02/03/rebase-v-merge-in-git/

I really should go back and start making new blog posts... I'd dropped the ball because I ended up on a few enterprise SCM (software configuration management) gigs shortly after.

Reply on news.ycombinator.com