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

vsb>У этого подхода я вижу два минуса:
vsb>1. rebase требует force push. Если зачем-то над этой веткой кто-то ещё работал, возникает хаос. Также теряются исходные коммиты, если при rebase была сделана ошибка, то её уже не исправить. Частично решается созданием новой ветки при каждом rebase-е, но тогда в репозитории будет множество веток, которые надо не забыть подчищать (и не перепутать при подчистке).
Это хорошо работает в условиях короткоживущих веток. Если у тебя ветки маленькие, два-три коммита, живут два-три дня, то хаосу возникнуть в общем-то негде.
Если ветка большая, то ребейз лучше оставить на потом. Т.е. вначале толпой долго пилили, допилили, решили, что готово к мержу — договариваетесь, делаете ребейз, ещё раз всё проверяете каждый коммит и мержите.

vsb>2. rebase это сложно для понимания и применения, UI при rebase менее очевидный, при разрешении конфликтов разработчик не видит своих будущих изменений.
В IDEA сделали отличный UI для rebase.

vsb>Спагетти. Каждое изменение вносится в исходную ветку через merge. При визуализации разобраться в этом решительно невозможно.
Теоретически тулзы позволяют улучшить визуализацию. Например, скрыть мерж-коммиты.

vsb>Плюсы/минусы аналогичны минусам/плюсам выше.
vsb>Также у меня есть такое ощущение, что Git в целом больше заточен именно на подход с merge-ами. Это не технический аргумент, но я никогда не любил идти "против течения" и использовать инструмент не так, как его проектируют.
Как минимум, наличие довольно мощных rebase-команд в стандартной поставке самого git говорит об обратном.

vsb>Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?
В своих ветках ребейзю по полной, в том числе reword/fixup/squash/etc, каждый коммит стараюсь причесать. Если с кем-то работаю над некой веткой, то договариваюсь о стратегии с участниками.