Beware: git(hub)+git+subversion= many epic fails...

Представь, что у тебя в руках стопка тарелок, и на сервере (origin) стопка тарелок.
git rebase origin/master - значит что стопка на сервера берется за основание и пытается привести к тому виду которое у тебя на руках.
То есть после этой операции ты имеешь origin/master + delta, где дельта твои коммиты (если предположим, что коммитил ты один).
После этой операции можно спокойно пушать. rebase также убирает ненужные коммиты типа merge commit.

Я например обхожусь без мержа.

git checkout -b featureBv2
git commit
git push origin featureBv2:master

если кто то до меня пушнул нужно сделать так:
git fetch origin
git rebase origin/master - это приведет к тому что мой коммит "всплывет" в истории наверх даже если был сделать до последних изменений в мастере
git push origin featureBv2:master

Я вот когда начал git изучать, сначала искал QuickRefernce, типа основные команды посмотреть - ничего доступного для бысторого вьезжания сходу не нашёл. Потом начал смотреть краткие статьи с описанием - то что я видел, всё написано сумбурно и полно горячей мочи от восторгов. Особенно умиляют советы типа, для лучшего понимания нужно изучить структуру данных git'а - вот это вообще пипец.
Далее нашёл какое-то руководство(может даже с kernel.org, но могу ошибаться - читал с телефона) - там те же саки.
В итоге набрёл на вменяемое руководство-книгу Pro Git, которая есть и на русском, на английском, и на других языках. Вот собственно - http://progit.org/book/ru/ , первых трёх глав должно хватить для начала.
Конкретно про rebase - http://progit.org/book/ru/ch3-6.html .
Есть описание ещё тут http://kernel.org/pub/software/scm/git/docs/git-rebase.html , особенно иллюстративен пример где есть master, next, topic:
изначально:

o---o---o---o---o master
\
o--o--o--o--o next
\
o---o---o topic

делаем git rebase --onto master next topic, получаем:

o---o---o---o---o master
| \
| o'--o'--o' topic
\
o--o--o--o--o next


-----
Для сплющивания нескольких коммитов, в один, я rebase не использую, так как считаю идеологически неверным - зачем терять инфу? merge сделает тоже самое сплющивание, да ещё и сама цепочка коммитов останется.
rebase я использую в следующем контексте:
- есть проект
- перед непосредственно работой, нужно выполнить некоторые настройки системы автосборки - для этого я завёл отдельную ветку - BuildConf (можно вынести все файлы настройки в не версифицируемую область, то есть как советует svn иметь conf.template, и каждый разрабочик копирует в сonf, и правит уже его. но зато так, я получу историю своей настройки сборки проекта)
- feature-ветки я ответвляю от BuildConf
- когда feature ветка готова, и должна смёржится в master, я её снимаю с головы BuildConf и сажаю на master (то есть rebase), а потом мёржу в master (с опцией -no-ff, чтобы всегда merge'ем был один коммит). Это для того, чтобы настройки BuildConf не попали в master.
- после merge'а feature, master ушёл вперёд от разветвления с BuildConf, если для работы над следующей feature в рабочем дереве должны быть изменения от предыдущей feature, то просто пересаживаю BuildConf на голову master (то есть опять rebase).
- если во время работы над очередной фишкой, нужно поменять конфигурацию сборки, то есть сделать в неё коммит с изменениями, то feature пересаживается на новую голову BuildConf (опять rebase)