On Sun, Jan 4, 2009 at 4:32 PM, Victor <[email protected]> wrote: > guessing this is why I've never really had to worry about git-rebase,
And neither have I, except to try out stuff. However, git rebase has an "interactive" option which is absolutely awesome, and I use it all the time, typically as "git rebase -i origin/master". Here's how it works (I'll skip the tedious --> symbols, since there are no branches here): A B ..... J A is where origin/master is, and J is where your local master is. You're not actually using "topic" branches because the changes aren't that disruptive as to need that sort of quiet, "on the side" development. Now you want to push, but you realise that among B...J are some changes that are silly, just noisy stuff like a typo here or there etc., so you'd rather squash them into some other commit that had some real meat and avoid cluttering. You can afford to do this because you haven't pushed B...J anywhere yet -- don't forget you shouldn't (normally) rebase stuff that's already been pushed. So you do "git rebase -i origin/master". You'll end up with an editor that shows something like this: pick f9112c4 some commit pick 7f3e7fa some other commit pick a0d60f2 yet another commit pick 41c821a still another one # Rebase 2b4f9cb..41c821a onto 2b4f9cb # # Commands: # p, pick = use commit # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. You can do some amazing things here. You can change the word "pick" to squash to have that commit be combined with the one above it. You can change it to "edit" to make git stop at that point and allow you to make further changes. You can delete some of those lines to just *forget* those commits (they'll be gone, be careful!). And best of all, you can re-order the lines. I will typically reorder them to get related ones together, then squash the "fix a silly typo" type of commit onto the previous one, then save the file. Pretty cool actually... sort of like cherry-pick, but more than one at a time :-) > but I have a feeling it's almost the same as doing what I've done in > the past when working in pairs, which is to: > > $ git fetch > $ git merge origin > <solve potential conflicts> > $ git push, > (right?) It is functionally be the same, and as I said in a small project with few devs you don't *need* to rebase, but there is a difference: if you look at the git graph using "gitk --all" for the two cases you will see the difference. Of course rebase does not change the end result -- it just shifts the conflict resolution etc., around a bit, and makes the history linear. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
