мерзавец выпускает управление

См. Следующие сообщения в блоге Junio ​​C Hamano (сопровождающий git):

• Завершение слияния
• Никогда не слияние обратно (о ветвях, разветвленных с намерением не слиться обратно)
• Раннее разрешение конфликтов / зависимостей между тематическими ветками
• Развлечения с удаленными ветвями (1)
• Развлечения с удаленными ветвями (2)

Взгляните также на страницу руководства gitworkflows .

What you are asking is a typically a merge workflow problem: what to merge from where to where.

But you also need to remember that in a DVCS, a merge will also be influence by publication considerations (are those branches pushed to local repositories, or public ones)

"master" branch in particular is the one visible by default when someone clone your repo, meaning it should reference what you consider most useful to that user/developer. (since other branches are not referenced locally by default)

1/ When I add some feature on release-2 and it should go to 3 as well, but not to 1

You can indeed merge r2 to master, after having made a number of commits to r2 in order to achieve the necessary evolutions. That way, only a limited number of commits are visible in master, avoiding "commit cluttering".
Однако для r3 вы можете выбрать то, что вам нужно, из r2, если r3 отправляется и публикуется. В противном случае вы можете переустановить r3 на r2. См. « рабочий процесс git и перебазирование против слияния », вопрос

2 / Когда мне нужно изменить sth во всех версиях, следует ли мне сделать это на главном сервере и выбрать его для всех веток?

Вы должны сделать это на r2, а затем слить на master и r1 и r3. Таким образом, к этим ветвям добавляется только одна фиксация.

3 / Следует ли мне поддерживать master в актуальном состоянии с помощью новейших (ветка выпуска-3) или, скорее, разработчика в выпуске-3 и слить с мастером непосредственно перед тем, как мне понадобится ветка выпуска 4?

Это зависит от того, что вы хотите, чтобы другие коллеги видели, когда они клонируют репо.
But from 1/, I gather master is representing r2 (current development) and not r3 (future, long-term refactoring)

4/ When I fix sth on release-1 or release-2, should I merge or cherry-pick it to master or rather?

• r1: cherry-pick: not all what you are fixing on r1 is meant to be merged to current development.
  Actually, I would rather cheery-pick r1 fixed on r2, make sure everything work there, and then merge on master.
• r2: merge. If master represents r2, a simple merge is enough.