Какие version control практики используют топ компании?

Одним из моих удивлений, когда я начал работать в топ компаниях, стало то, что они, в основном, используют так называемый Trunk-based development. В то время как в других, маленьких и средних компаниях, использовался, в основном, Gitflow Workflow.
Я начал работать в FAANG компаниях 6 лет назад. В то время, в более маленьких компаниях, стандартом был Git Workflow. Это когда есть множество долгоживущих feature бранчей, есть develop branch, есть release branch, который периодически мержится в trunk. На тот момент я думал, что такой подход более безопасный. Когда я пришел в Amazon, а потом в Facebook, я с удивлением узнал, что они используют Trunk-based development. В таком подходе, есть только trunk/master и все разработчики делают очень маленькие инкрементальные изменения, которые тут же попадают в trunk и через несколько часов попадают в продакшен. Это позволяет организовать настоящий CI/CD (Continuous Integration/Continuous delivery).

Как выглядит типичный процесс разработки и деплоя кода при таком подходе?

Разработчик получает или создает таску, над которой он работает. В рамках одной таски разработчик может сделать одно или множество изменений кода. Каждое такое изменение кода проходит code review и не должно ломать trunk. При этом одно такое изменение не обязательно должно полностью реализовать функциональность, которую описывает таска. Например, в первом code change вы можете объявить некие интерфейсы, без реализации, во втором, реализовать методы этих интерфейсов, в третьем добавить вызовы этих методов. Каждое такое изменение кода должно сопровождаться добавлением соответствующих автоматических тестов (unit tests, integration-tests, performance tests, end-to-end tests, UI tests и т.д.). Т.к. выделенных QA обычно в таких компаниях не бывает. Все тестирование делается самими разработчиками. Как только code review пройден, все комментарии и замечания к коду учтены, то разработчик делает push в trunk. Это изменение последовательно проходит через множество шагов в рамках deployment pipeline. Вначале это все компилируется и собирается. Далее прогоняются автоматические unit тесты. Далее эта сборка деплоится на выделенный тестовый сервер, на котором прогоняются интеграционные тесты, перфоманс тесты и т.д. Далее деплоится на canary сервер (на один продакшен сервер, например). Где собираются разные метрики, на основе которых делается автоматическое решение деплоить ли эту сборку далее или сделать rollback. Если все хорошо, то далее эта сборка волнами попадает на все остальные сервера. Все эти деплоймент шаги выполняются автоматически.

Чем отличаются эти два подхода можно посмотреть, например, тут https://www.toptal.com/software/trunk-based-development-git-flow

Пишите в комментариях, какие практики используются в вашей компании.