As a concrete example, say I refactor to rename method X to Y in patch A. Now I write two new feature patches, B and C which call that method. Typically I will submit them as A<-B<-C to gerrit, and only rebase to break them up into A<-B and A<-C if there's some problem getting B merged. But in the gerrit model these are three separate reviews for A, B, and C regardless; the dependencies just affect merge order (B/C won't be merged until/unless A is merged).

Having used both the gerrit and github models, I have to say that I strongly prefer the gerrit model -- especially for projects where reviews can take a while. Often successive patches for unrelated features in a given developers' tree will incidentally depend on each other -- for example, a refactoring done for one feature affects the name of a method used in a subsequent patch. The patches could be rebased to reorder the refactoring, or the refactoring could be split out into its own patch, but this is usually unnecessary make-work. The gerrit model is very convenient because it allows you to indicate dependencies without lumping the patches/features/reviews together. If changes are requested (or if reviews come in a different order than you expected) you can rebase/reorder patches and re-upload them to update the dependencies.