Мы тоже как-то обсуждали подобную тему в организации и пришли к компромиссу и такому выводу:

Если есть связанные между собой задачи, как у вас, то делается одна общая задача (например #1) и подзадачи (#2, #3, #4). В каждой подзадаче описываете что нужно реализовать конкретно. В общей задаче - общее название и описание (привет КЭП) и перечисляете список подзадач для неё.

В Github, Gitea, Gitlab есть функционал "связанные задачи". Когда одну задачу нельзя закрыть пока не закрыты другие. Связываете общую с подзадачами.

У себя на ПК делаете общую ветку от дева, например task_1, но делаете всё последовательно с коммитами с текстом в виде #задача #подзадача - текст, пример:

"#1 #2 - изготовлен сервис по проверке юзеров на андройдность"
или 
"#1 #3 - произведён рефакторинг солюшена на облюпшен"
и т.д. 

В итоге у вас всё льётся в один главный таск, но при этом видно какой коммит к какой подзадаче относится. Конечно, надо договориться, что не выполнять все подзадачи разом или переключаться туда-сюда. Но это вопрос договорённости.

Все эти подзадачи отправляются постепенно на CodeReview, Тестирование и закрытие. Как только всё выполнено - главная задача идёт на слияние с dev

Может решение не лучшее - но как вариант

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

Административная

В моей практике такое один раз возникло - команда была поставлена в ситуацию, когда любой вариант решения отсекался как неприемлемый. Но у нас был Adgile/Scrum. Поэтому пишется письмо от команды, что мол, заблокированы, не можем решить, предлагаем такие варианты решения + сроки + риски (это крайне обязательный пункт) и письмо отправляется на вышестоящего менеджера. Естественно, он в 90% случаев это игнорирует (это штатная ситуация, но это нужно сделать, нельзя перепрыгивать). Потом письмо отправляется на менеджера выше с пометкой "команда поднимает красный флаг" (в теме письма просто в начале пишется [RED FLAG]). Красный флаг - это остановка спринта и перепланирование. В больших командах это может привести к существенным потерям и на это редко идут. Почти всегда менеджеры между собой договариваются и ситуация решается быстро.

Способ хорош, но его нужно проворачивать аккуратно. К примеру, при написании письма в первых 7-10 словах письма должно быть уже написано, что команда хочет (представьте себе, что письмо открылось на телефоне как нотификация и видно пару строк. Адресат по ним должен понять ситуацию). Не нужно никого обвинять и жаловаться на "плохого менеджера".

Планирование

Такая ситуация может возникать, если задача плохо распланирована и оформленна. И тут вина бывает как команды, так и менеджеров. В любом трекере задач (jira к примеру), есть возможность связывать задачи. Иногда бывает, что если одна задача зависит от другой, то возможно, первую задачу нужно сразу разбить на две или три и оговорить, что вот это важная часть, другие задачи от нее зависят. Да, это не очевидно бывает, но приходит с опытом. Ретроспективы обычно этому помогают.

Используем возможности git

В гите есть чудная штука - cherry-pick - она позволяет "нахватать" себе других коммитов. Синтаксис очень простой - cherry-pick <хеш-коммита>. Но у этого способа есть несколько минусов.

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

Я в своей практике использовал такой подход. В свою ветку делал cherry-pick нужных мне изменений и делал свой код. Саму таску отмечал как "должна быть закомичена после", после чего в паралель делал текущую задачу и пинал тех, кто должен сделать ревью/одобрить коммит/pull request.

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

Что можно делать ещё в данном случае?

• Можно попробовать все таки договорится. Люди очень часто боятся пробовать что то новое, если они это плохо понимают.
• Можно сделать по другому. Написать менеждеру/директору мол, так и так, возникла такая ситуация, пытались решить. Не получается. Могу делать как хочет коллега, но тогда время на выполнения задач нужно будет сразу умножить на 2 (или три). Но нужно помнить, что если письмо пишется не технарю, то оно должно содержать варианты решения с оценкой рисков и содержать просьбу совета. Менеджеры любят такую постановку и обычно быстро все решают.
• Всегда есть возможность попробовать выбрать другую компанию.

Ситуация распространнёная. Чекаут от непротестированной и неапрувленной ветки может вызвать существенную боль. Если окажется, что в исходной ветке были проблемы. Придётся затаскивать изменения в несмёрженную и ребйзить / переписывать код в ответвлениях. Или вносить правки в ветку-наследницу, которая не имеет отношения к возникшей проблеме.

Что на практике?

• Задача забуксовала в тестировании / фиксинге / ревью

  Конечно не стоит основывать решение новой задачи на коде, который не является достоверно рабочим. Или не проходит банально по кодстайлу. Доводим задачу до конца, мёржим в dev отпачковываемся.

• Задача является частью жирной фичи. Пока основные части проекта относящиеся к фиче не будут готовы, код не попадёт в dev.

  • Отважный путь — создать пачку моделей и интерфейсов без реализации, которые будут замёржены до завершение основных задач. Сложен он глубокой аналитикой, большая вероятность переоптимизации или же недостаточной проработки. Хорош тем, что над связанными задачами могут работать параллельно несколько человек.

  • Компромисс — завести фича-бранч, который смотрит в dev. Остальные ваши задачи берут начало от него и в завершении флоу попадают в него же. Чистый dev и прозрачное разделение на задачи.