Возможно мне везло с проджект-менеджерами, но на двух моих местах работы в качестве разработчика в команде, практически единственным местом, где возможны были конфликты транка и бранча были различные словари - хедеры с энумами, константами и тп; в затрагиваемых веткой исходниках  изменения были всегда несущественны, решать конфликты было более чем просто.
То есть схема работы была следующая: такой-то функционал решено разрабатывать в отдельной ветке, создаётся бранч, ведётся разработка, затем 1м (!) коммитом вливается с меткой "мерджед бранч такая-то". Лично я  чаще всего при этом вообще не использовал merge - делал дифф и накладывал на транк, с "ручным" добавлением новых файлов.
  
   То есть постоянного мерджа из ветки -> в транк -> в ветку -> в транк  я ни разу и не видел.  В данном случае одновременной модификации одного и того же кода действительно необходимо какой-то сценарий слияния, но это немного другая идеология разработки, вы не находите?
И я правильно понял, что git rebase - это те же самые решения конфликтов, только в профиль?

>svn merge r???:??? (тут игра в сапёра. Во-первых, не ошибиться бы с
>номерами коммитов. Во-вторых, коммиты в ветке окажутся позади отмерженного)

Действительно, надо знать номера ревизий, определять их по stop-on-copy опции.

насчёт:
>Перестраиваем коммиты, ибо было туча промежуточных с отладкой (чтобы другие девелоперы ознакомились с мыслями и догадками)

так ведь остались коммиты в бранче, зачем дублировать в транк? Лучше одним коммитом заливать, чтобы не было "я обновился когда ты не всё залил".