From: David Gudeman 
  Sent: Thursday, June 13, 2013 7:12 PM
  Subject: [git-users] what is the point of rebase?

  I've been getting to know git recently as part of some work I needed to do, 
and I love the easy branching and merging, but I have to admit that rebase is 
confusing me. I'm not confused about what it does (I don't think); I'm confused 
about what the point is. As far as I can tell, rebase is just the same as doing 
a merge and then throwing away some history. Why throw away the history? All of 
the documentation I can find just refers to making history "clean", but the 
history doesn't have to actually BE clean to LOOK clean. So why?

  Or here is another way to ask the question. Suppose git repositories had a 
special flag that you could put on a branch that said, "don't show this branch 
in histories or push it or allow it to be pulled unless the user does something 
special to ask for hidden branches". Then suppose git had a merge-and-hide 
command that would do a merge and then set this flag on the topic branch to 
effectively hide it unless the user really wants to see it. What does rebase 
accomplish that merge-and-hide would not?

  I keep feeling that there must be something else, otherwise why deal with the 
potential negative consequences of deleting history unrecoverably? All of the 
documentation on rebase talks about the problem of rebasing a branch out from 
under someone who is still working on it. So what is the advantage of rebase 
over merge-and-hide that makes it worth dealing with this problem.
Rebase is a way, within a distributed system, of noticing that the world has 
moved on since you started on your magic topic branch. 

So you want your magic topic branch to cleanly apply to the New World Order of 
the upstream repo, hence you 'rebase', or transfer, your series of nice small 
changes (commits) to the latest upstream reference point (often tip of 
master/production), and while doing the rebase, you fix all the conflicts (with 
the NWO changes) as you go to create a clean sequence, and then you will have a 
commit/patch series that can either be fast forward applied, or merged without 

Obviously (?), having done your rebase you will have to style check, compile 
and test you new magic code to see if it actually works as planned without any 
regressions (and fix a few minor mistakes). By which time the NWO has moved on 
again, so another quick rebase gets you to the head of the queue, and you are 
awarded tea and medals.

The other scenario is that you are working on say git itself and you send in 
patches for review, which end up with fixups and comments, so you have to 
continue to rebase your own work forward to the relevant start point, 
especially if there is an overlap with other patch series.

The "problem" doesn't exist in other, non-distributed, systems because of the 
restrictive check-out - check-in process which nails both feet to the floor to 
stop you going round in circles (and limits progress!). Rebase lets you leap 
ahead and catch up with the latest and greatest code release, or a 
collaborators code, or wherever. 


You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to