Thanks for a great explanation of git-rebase :). I was under the impression that git-rebase would go back to "A" when resetting and not speed up to "E". Which would... not make much sense (dunno why I thought that).
I'm still studying at the University, so I mainly use git as a backup medium; a rationale documentation system; and to make my code more portable (as in when I switch from school computers->home->back) without too much copying and in a more safe way. It's mostly just me or at most two people working with a project/assignment, so I'm guessing this is why I've never really had to worry about git-rebase, 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?) On Jan 4, 4:08 am, "Sitaram Chamarty" <[email protected]> wrote: > Firstly, it is important to note that you should never (or almost > never) rebase a branch which has already been pushed to anyone else -- > it causes all sorts of problems for them, because you've changed > "history" behind their backs. > > With that out of the way... > > What rebase does is that it "linearises" the history of the final > merged master branch. > > Let's say your changes look like this: > > A-->B-->C-->D-->E > \-->P-->Q-->R > > You opened a topic branch when master was at A. Now the topic is at > R, master at E. A merge then combines E and R into a new node, which > may be "F". But the history tree now has a non-linearity in it. > > If you rebase, the history looks like > > A-->B-->C-->D-->E-->P2-->Q2-->R2 > > where P2, Q2, and R2 are the same textual change as in the original > P/Q/R, but they are made on top of E instead of on top of A. > > One practical reason to use rebase is described very nicely > athttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bise... > In general, it is easier to debug stuff if history is linear :-) > > Another one is that without a rebase, a master that receives a tree to > pull cannot easily cherry-pick changes. Well he can, but the chances > of conflicts are a little higher cherrying picking a change from an > older version of your tree than one built on your latest tip. In the > example above, if master were offered the PQR tree for a pull, let's > say he decided to take only change Q because the other 2 were not > acceptable. Picking up Q , which is built on A, when master is > currently at E, puts the onus of any conflict resolution on the person > handling "master". (I guess he could say "hey topic guy, I like Q, so > give me a branch which only contains Q and I will pull from there", > but I suppose that wastes time...) > > However, if the topic guy take the trouble to rebase, and then offer > the master a P2/Q2/R2 branch for a pull, the chances of the "master" > maintainer finding a conflict are much lesser, because Q2 is built on > top of E, which is either the current master tip or very close to it. > > This **really** makes a difference if your A was old (which can happen > if your topic was a complex feature that took you a while to develop > and get stable enough to offer for a merge with master, so that > meanwhile master has moved quite a bit). > > A third reason is that many people like the master project history to > be linear rather than full of merges. For small teams or frequent > pushes to master this may not be a problem, but for large projects > like Linux, where a single change can go up many levels of review and > approval before it gets to Linus' tree, it makes a lot of difference > -- the project history would be horribly convoluted! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
