Стратегия работы Git - много функций, очень частые выпуски

вот описание моей повседневной работы:

Два разработчика работают над множеством мелких функций или исправлений, скажем 3- 4 в день на каждого разработчика. Мне нужно работать над функциями A - B - C одновременно, пока мой коллега работает над функциями D и E.

Понедельник : Функция A отправляется на промежуточный сервер для проверки клиентом. Функция B отправляется на тот же промежуточный сервер для проверки клиентом. Функция D отправляется на тот же промежуточный сервер для проверки клиентом.

Вторник : Мы получаем одобрение от клиента для A и D (но не для B). И им нужно немедленно приступить к этим изменениям.

Среда : Функция C отправляется на тот же промежуточный сервер для проверки клиентом. Утверждение для B наконец получено.

Четверг : Функция B должна быть немедленно запущена в производство.

Пятница : В последнем производственном выпуске обнаружена ошибка, и нам нужно вернуться к предыдущей версии.

Это нельзя рассматривать как процесс, похожий на Scrum, потому что нет возможности группировать функции в истории или планировать спринт. Это больше похоже на процесс обслуживания (может быть, Канбан?).

Не могли бы вы привести пример того, как бы вы справились с этим с помощью Git? Предположим, что прямо сейчас у нас есть только одна главная ветвь, и всякий раз, когда мы хотим что-либо отправить на стадию или производство, мы должны «git pull» сделать все изменения живыми (даже нежелательные). А как насчет git "cherry-pick" для получения конкретных коммитов? Одна ветка на каждую функцию кажется слишком обременительной, поскольку у нас слишком много функций. Если бы вы могли привести конкретные примеры команд и веток Git (только для того, чтобы показать основную идею, не обязательно быть на 100% правильным), это было бы здорово.

Спасибо.