

The Case for Git Rebase - dasil003
http://darwinweb.net/articles/86

======
timdorr
I'm using rebase a _lot_ right now. Our designer is currently going through
our main development branch and is ripping things apart, redoing styles, etc.
At the end, we were faced with a mega-merge back into our develop branch of
his extensive changes. Instead, he just pushes his visuals branch out and we
rebase our topic branches against it. That means no massive merge session at
the end, as all the conflicts are resolved by the people who created them.
Simple as pie.

------
div
I've been using git for little while now, and started out using rebase in the
manner described here. I did some experimenting first using gitk and a few git
branches to grok what rebase actually did, and then figured I pretty much
always wanted to rebase, unless working on a branch that was 'public' (which
other people will pull from).

So my strategy has been, rebase for all local branches, merge for all public
branches.

That being said, I'm still quite new to git, so if anyone can explain why that
strategy is flawed, I'm happy to listen.

~~~
weavejester
I sometimes it's useful to use merge to "group" a large set of changes that
all relate to one feature.

That said, if I'm working on a branch for any significant period of time, I
tend to push it to the remote repository anyway. It keeps it safe and shows
people what you're working on.

------
chmike
My impression is that rebase is used as a palliative to a short coming of log
history display. It would be indeed useful to be able to show only key
merges/commits log messages. This would imply adding some kind of level to the
logs so that they can be collapsed like function code in modern code editors.

~~~
dasil003
That doesn't help git-bisect which is really the most significant of the three
issues.

------
rue
Merging and rebasing both have their benefits and use cases. Just do not fall
for the "squash everything into one commit and rebase" BS recently afflicting
otherwise rational people.

~~~
docgnome
I can see squashing a bunch of commits when you make 30 junk commits just so
you can push them off your box for safe keeping. Assuming that no one is gonna
pull from where you pushed, or you just don't care about other people, I see
no problem with that as long as the new commits are smallish discreet units.
Making huge commits will hurt you when you try to git-bisect.

------
docgnome
Rebase is useful. Someone said it was like a boomerang with a chainsaw on both
ends. You better pray that it doesn't miss it's target and come back to get
you.

