The Case for Git Rebase

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.

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.

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.

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.

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.