Что мы на нём делаем
Git — не предпочтение, а среда. Но то, как команда им пользуется, — вполне реальный выбор, и он проявляется в том, насколько с кодовой базой удобно работать через год.
Наш вариант по умолчанию: короткоживущие ветки от транка, который всегда собирается, один отревьюенный пул-реквест на изменение и CI, гоняющий тесты, линтер и сборку на каждый пуш. Коммиты пишутся, чтобы их читали: сообщение объясняет зачем, а не пересказывает диф.
Где он нужен
В каждом проекте, включая работу внутри репозитория клиента. Когда мы входим в существующую команду через усиление команды, мы принимаем их модель ветвления и правила ревью, а не приносим свои: единообразие внутри одного репозитория ценнее, чем объективные достоинства любого конкретного процесса.
Когда мы его рекомендуем
В том виде, что описан выше: trunk-based разработка с маленькими, часто вливаемыми ветками. Долгоживущие фиче-ветки — источник боли при мерже и устаревшего кода, а расплата приходит через недели после решения, которое её вызвало.
Возражаем мы против процесса ради процесса: обязательного squash, жёстких форматов сообщений или модели ветвления с пятью постоянными ветками в команде из трёх человек. Смысл в истории, по которой можно сделать bisect, и в ревью, которое что-то ловит, а не в церемониях.