Здравствуйте, IID, Вы писали:

IID>Коллеги, поясните пожалуйста, как разруливаются зависимые задачи при использовании PR ?

IID>Поясню на примере. Есть 3 высокоуровневые задачи:
IID>1) вывести на экран число 42
IID>2) прочитать информацию из файла и записать в другой файл
IID>3) прочитать информацию из файла и вывести её на экран.

IID>Для реализации этих задач создаём базис, 2 низкоуровневые задачи
IID>а) абстракция вывода на экран
IID>б) аобстракция работы с файлами

IID>Низкоуровневые задачи одинаково приоритетны для высокоуровневых и одинаково абстрактны чтобы, например, не иметь соблазна реализовать низкоуровневую задачу в рамках (ветке) высокоуровневой.

IID>Реализуем низкоуровневые в своих ветках, пушим, создаём PR.
IID>И... наступает ступор. Т.к. пока не пройдёт ревью и они не попадут в dev — мы не можем приступать к реализации ни одной из высокоуровнеых задач!

IID>Создавать бранч высокоуровневой задачи от бранча низкоуровневой как-то неправильно.

На начальном этапе нормально, вообще без проблем.
Потом отребейзишь на dev, см. ниже.

IID>Да и невозможно в случае задачи-3, ей нужны обе низкоуровневые задачи одновременно.

Merge.
Ответвляешься от одной из веток, вливаешь туда вторую (или ответвляешься от чего хочешь, вливаешь туда по очереди обе ветки).

IID>Предположим, других задач сейчас больше нет.
IID>Что делать ?
IID>I) Сидеть сложа руки, пока не пройдёт ревью и dev станет актуальным ?

Ну рсдн читать, в политику писать там, в авто-мото-вело... )

IID>II) Сделать высокоуровневые задачи в своей локальной ветке.

Ну да, именно так.

IID>Затем перенести вручную файлы высокоуровневой задачи "на авось", в её бранч от старого dev.

Перенос изменений из произвольной ветки в другую произвольную — это cherry-pick. Только это здесь сейчас не нужно.

IID>В таком случае проверить этот ручной перенос не получится. Даже простой build, не говоря про какие-то тесты.

Немножко не так.
Делаешь высокоуровневую задачу, отлаживаешь её, убеждаешься, что всё работает.
К этому моменту низкоуровневые пройдут ревью и вольются в dev.
Дальше ребейзишь свою ветку высокоуровневой задачи на dev (ну или ответвляешься заново от дев и cherry-pick'ом переносишь изменения — если с ребейзом совсем плохо будет, но до этого думаю не дойдет).
И вуаля — отправляешь сделанную задачу на ревью в пулл-реквест.
Если ты высокоуровневую уже сделал, а низкоуровневые ревью еще не прошли — то сделанные высокоуровневые стоят в очереди и ждут. Как только вольются зависящие низкоуровневые — ребейзишь и отправляешь ветку на ревью, она легко и быстро отребейзится.

IID>III) Бранчеваться от "старого" dev, мержить "подвисшие" PR задачи в этот бранч ?

Ну да. Ну как старого — на момент бранчевания он как раз свежий. )

IID>Для случаев II) и III) также непонятно как гарантировать правильную очередность слияний зависимых PR.

Если два пулл-реквеста конфликтуют между собой — чинить конфликты всё равно придется.
Если это все твои ветки и ты их уже починил и они висят в очереди на ревью — то вливаешь это всё к себе и вуаля.
Если это чужие конфликты и их еще не починили — то или ждать, пока починят (неважно, вольют в dev или оно в отдельной ветке будет стоять в очереди ждать ревью — лишь бы было починено), или временно починить самому, если совсем невтерпеж. Но чужие лучше подождать. Типа, фича "вывод числа из файла на экран" зависит от фич "работа с экраном" и "работа с файлом", они пишутся другими разработчиками и еще не готовы.

Вроде на все вопросы ответил. Спрашивай, если что.

Очень рекомендую почитать про гит вот эту книгу, на русском там тоже есть. Сразу многое станет понятно.