Моделирование истории в централизованных и распределенных системах управления версиями

[linuxoid]

Интеграционный сервер собирает все ревизии или ревизию, которую указывает, например, Test Lead
QA команда решает сама или с помощью менеджера, какую версию им тестировать
Разработчик обновляется не на “последнюю версию”, а решает сам, на основании какой ревизии должен быть создан новый коммит

Мне кажется, «решает сам» не вполне отвечает на вопрос «на какой ревизии тестировать» или «кто решает, какая ревизия является „главной головой“». Вы правы, что это зависит от процесса разработки. У вас были замечательные иллюстрации, а вот вывод получился скомканным. Есть ли у вас что предложить конкретного, конкретный сценарий?

// Плюс, вопросы: как этот самый разработчик должен решать, от какой ревизии ему плясать. Кто потом будет все эти головы мержить?

[Cortlendt]

Часть ваших вопросов может быть отвечена в этом топике.

Как правило разработчик решает, исходя из какой ревизии создавать новый коммит, основываясь на том, в какие ветки должен попасть его код. Допустим багфикс релиза он фиксит в релизной ветке и переносит изменения во все ветки, где этот багфикс актуален.

Это все сугубо индивидуально для процесса, проекта и задачи, универсального ответа нет.