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

спасибо за ликбез.

>> И имхо запоминание можно заменить на документирование.

увы, в наших реалиях документирование не работает. документация слишком быстро устаревает. и тратить время на разборки - так себе выход. лучше стараться минимизировать влияние человеческого фактора.

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

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

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

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

>> нет необходимости держать testing работоспособным 100% времени

поскольку у нас сейчас SVN, то это - основное требование для комита - приложение должно собираться  запускаться. да, какой-то функционал может быть сломан, тот который в разработке скорее всего и будет сломан, но любой должен иметь возможность обновиться и запустить приложуху у себя локально, либо в любой момент обновить тестовое окружение. Возможно, в случае с Git можно как-то по другому, но я пока слабо себе представляю как - для каждой ветки поднимать отдельный инстанс, на который направлять тестеров? Они не будут рады. И не только они. И потом все равно нужно тестировать testing ветку, из которой изменения пойдут дальше...

>> если кто-то поломал testing, всегда есть возможность посадить его вне очереди исправлять проблему.

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