Здравствуйте, vsb, Вы писали:

vsb>1. rebase требует force push. Если зачем-то над этой веткой кто-то ещё работал, возникает хаос.
В случае с "кем-то ещё" есть git push --force-with-lease, более безопасный чем git push --force. Ну и к тому же, git fetch -p @{U} и там уже смотреть что делать с изменениями с удалённого репозитория (иногда эти изменения -- твои).

vsb>Также теряются исходные коммиты, если при rebase была сделана ошибка, то её уже не исправить. Частично решается созданием новой ветки при каждом rebase-е, но тогда в репозитории будет множество веток, которые надо не забыть подчищать (и не перепутать при подчистке).
Нет, есть git reflog, умеет отмирать со временем сам, или принудительно -- с помощью git gc. Вот что в git не залетает в историю, так это индекс, который можно случайно грохнуть git reset --hard.

vsb>если при rebase была сделана ошибка, то её уже не исправить
Если имеется в виду исправление сложных наборов патчей на своей ветке при интерактивном варианте, то тогда да, соглашусь: после git rebase --continue подправить патч можно будет только в следующей сессии интерактивного git rebase. Вроде, это можно частично решить с помощью git rerere, но не уверен.

vsb>2. rebase это сложно для понимания и применения, UI при rebase менее очевидный, при разрешении конфликтов разработчик не видит своих будущих изменений.
vsb>rebase это сложно для понимания
Нет, совершенно. Это просто git reset на определённый коммит и git cherry-pick на стероидах.
vsb>rebase это сложно для ... применения
В некоторых случаях -- может быть. Например, если на topic-ветке затеяли рефакторинг, то тогда, скорее всего, придётся подчищать каждый коммит. Или, например, если от topic-ветки растут ещё ветки. Тогда приходится делать git rebase для каждой ветки отдельно в правильном порядке, так как git совершенно безразлично что на что перебазировать. Я когда-то писал для этого скрипты, умеющие такой rebase автоматизировать, но чем меньше сущностей -- тем проще + не нужно тянуть за собой свой набор скриптов на каждую машину.
vsb>при разрешении конфликтов разработчик не видит своих будущих изменений
Смотря куда смотрит. Для этого есть как минимум git log --left-right @{U}...{U} (с троеточием), и добавление маркеров в commit message (если на проекте есть такое соглашение), и git trailers, и настройка $PS1 в bash (у меня, например, всегда видно количество изменений локально и с удалённого репозитория, если topic-ветка и её upstream-ветка указывают на разные фиксации). И это только перед началом rebase. Во время самого git rebase возможны другие техники.

vsb>Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?
* внедрение изменений с родительской ветки на topic-ветку — git rebase локально.
* внедрение изменений с topic-ветки на родительскую — git merge --no-ff --no-squash (локально или удалённо, зависит от того, как в неё принимаются изменения) после предварительного git rebase topic-ветки.

vsb>Также у меня есть такое ощущение, что Git в целом больше заточен именно на подход с merge-ами. Это не технический аргумент, но я никогда не любил идти "против течения" и использовать инструмент не так, как его проектируют.
Мне кажется, что git вообще ни на что не был изначально заточен. Это действительно stupid content tracker. Вот Mercurial заточен на merge, там rebase не привествуется вообще, и, если не ошибаюсь, по умолчанию даже не доступен, и позже пресекается public-фазами коммитов.