Можно ещё теоретический вопрос. Вот допустим git flow. Соотвественно, ветки master, develop, куча фич-веток. Задача - собрать код из нескольких веток для интеграционного тестирования не помещая в develop. Как сделать технически - я знаю. А вот как это делается правильно организационно? Стартует новая ветка куда все сливается? Orphan? Черри-пики с последующим ревертом? Да, по условию задачи должен быть задействован удаленный репозиторий, то есть история всей этой возни останется :)

Можно ещё теоретический вопрос. Вот допустим git flow. Соотвественно, ветки master, develop, куча фич-веток. Задача - собрать код из нескольких веток для интеграционного тестирования не помещая в develop. Как сделать технически - я знаю. А вот как это делается правильно организационно? Стартует новая ветка куда все сливается? Orphan? Черри-пики с последующим ревертом? Да, по условию задачи должен быть задействован удаленный репозиторий, то есть история всей этой возни останется :)

> для интеграционного тестирования не помещая в develop

так девелоп и нужен для интеграционного тестирования :)

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

Можно создать отдельную ветку и мерджить необходимые в нее через пулл реквест

Тогда ДФК хитрО кэшируется и не лезет за подгрузкой на сервер неявно.
Один из способов клиент-сервер оптимизации

тогда их надо мержить между собой

она не хитро кешируется, а каждые 38 строк бегает на сервер :)

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

А как тогда обеспечить качественную поставку? Сейчас у нас от develop стартует релиз в котором гоняются уже только супер-интеграционные тесты ;)

по гитфлоу stable as debian stone должен быть master.

То есть предполагается что после реализации фича-ветка попадает в develop и ошибки интеграции правятся прямо в develop?

а фризить девелоп - это противоестественно самому подходу :)

Он не фризится, просто закрыт от всего кроме mr, через которые прогоняются тесты