> интересно, где я спалился?

Гит распределённый, у (грамотных?) людей реквесты называются пулл-реквестами. Потому что нужно сделать пулл (стянуть данные с ДРУГОГО репозитория и смержить их), а не мерж (смержить данные из централизованного репозитория в него же самого только в другую ветку). На том же lkml Линуса просят смержить именно в форме "Линус, сделай пжл пулл-реквест к себе с репозитория git://some.git.repo/url.git из ветки for-linus". А в гитлабе это именно "Глав, смерж пжл в нашем ЦЕНТРАЛИЗОВАННОМ репозитории в свою ветку из моей".

Сам был удивлён, когда узнал, что в гитлабе, оплоте гита, используются "мерж-реквесты". Но, насколько я понимаю, сам гитлаб является, в общем-то, централизованной системой, построенной на основе распределённого гита. Так что подобная терминология объяснима.

> а если он заболел, в отпуск ушел, еще по каким-то причинам недоступен?
> когда человек должен что-то понимать или помнить - это плохо выстроенный процесс. я пытаюсь этого избегать.

А если в середине реализации issue заболел программист, который её реализует? Всё аналогично. На время болезни его подменяет другой, который видит всю историю ветки testing и принимает решения. Суть не в том, что есть только один человек, кто в курсе происходящего. А в том, что в один момент времени есть только один человек, ответственный за ветку, который может мержить и коммитить в неё и принимает решения относительно её прогресса. Если основной недоступен, то замещающему, конечно, потребуется время, чтоб войти в процесс. И имхо запоминание можно заменить на документирование.

Но у нас нет CI (и вообще хардкорной автоматизации), так что если что-то ломается, то это мешает только тестировщикам, а программисты варятся в своих ветках. И виновный исправляет, после чего ответственный за ветку вливает исправление. Тестировщики тем временем тестируют предыдущий слепок ветки или другой проект.

Насколько я понял вашу проблему, если у вас в разработке 10 задач, то 10 разных программистов в случайные моменты времени могут коммитить в testing, этакое коллективное владение кодом. Имхо это бардак. У нас это исключено, за ветку отвечает ровно один человек.

> workflow собственно я сам и пытаюсь выработать

У нас небольшая компания, и управление проектами организовано так, что а. нет необходимости держать testing работоспособным 100% времени (по сути мы реализуем согласованный объём работ, и только после этого начинается активное тестирование), б. если кто-то поломал testing, всегда есть возможность посадить его вне очереди исправлять проблему. Так что ревертов, подобных вашему, не требуется.