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.
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.
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.
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.
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.
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.
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.
8 comments
[ 3.7 ms ] story [ 34.9 ms ] threadSo 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.
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.