Коллеги, поясните пожалуйста, как разруливаются зависимые задачи при использовании PR ?
Поясню на примере. Есть 3 высокоуровневые задачи:
1) вывести на экран число 42
2) прочитать информацию из файла и записать в другой файл
3) прочитать информацию из файла и вывести её на экран.
Для реализации этих задач создаём базис, 2 низкоуровневые задачи
а) абстракция вывода на экран
б) аобстракция работы с файлами
Низкоуровневые задачи одинаково приоритетны для высокоуровневых и одинаково абстрактны чтобы, например, не иметь соблазна реализовать низкоуровневую задачу в рамках (ветке) высокоуровневой.
Реализуем низкоуровневые в своих ветках, пушим, создаём PR.
И... наступает ступор. Т.к. пока не пройдёт ревью и они не попадут в dev — мы не можем приступать к реализации ни одной из высокоуровнеых задач!
Создавать бранч высокоуровневой задачи от бранча низкоуровневой как-то неправильно. Да и невозможно в случае задачи-3, ей нужны обе низкоуровневые задачи одновременно.
Предположим, других задач сейчас больше нет.
Что делать ?
I) Сидеть сложа руки, пока не пройдёт ревью и dev станет актуальным ?
II) Сделать высокоуровневые задачи в своей локальной ветке. Затем перенести вручную файлы высокоуровневой задачи "на авось", в её бранч от старого dev. В таком случае проверить этот ручной перенос не получится. Даже простой build, не говоря про какие-то тесты.
III) Бранчеваться от "старого" dev, мержить "подвисшие" PR задачи в этот бранч ?
Для случаев II) и III) также непонятно как гарантировать правильную очередность слияний зависимых PR.
Здравствуйте, IID, Вы писали:
IID>Предположим, других задач сейчас больше нет. IID>Что делать?
как вариант, из 2х низкоуровневых сделать 4.
первые две — только абстракция в чистом виде (интерфейсы, простые модели, если надо, а также mock-реализация для целей тестирования).
идея в том, что их PR можно достаточно достаточно быстро протолкнуть в базовую ветку, после чего можно параллелить оставшиеся задачи, как оставшиеся низкоуровневые (настоящую реализацию заложенных абстракций), так и высокоуровневые (использование заложенных абстракций).
Здравствуйте, IID, Вы писали:
IID>И... наступает ступор. Т.к. пока не пройдёт ревью и они не попадут в dev — мы не можем приступать к реализации ни одной из высокоуровнеых задач!
Это вот почему вдруг? Стянул низкоуровневый рабочий бранч у коллеги, сделал ребейз своего хлама сверху и копай себе дальше.
IID>Создавать бранч высокоуровневой задачи от бранча низкоуровневой как-то неправильно. Да и невозможно в случае задачи-3, ей нужны обе низкоуровневые задачи одновременно.
Это только если у тебя строго 1 гит репозиторий, и странная религия, не позволяющая тянуть чужие бранчи из неглавного репозитория.
IID>Для случаев II) и III) также непонятно как гарантировать правильную очередность слияний зависимых PR.
Когда отладятся все три бранча, то и влить их в основной по порядку.
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, IID, Вы писали:
IID>>Предположим, других задач сейчас больше нет. IID>>Что делать?
C0s>как вариант, из 2х низкоуровневых сделать 4. C0s>первые две — только абстракция в чистом виде (интерфейсы, простые модели, если надо, а также mock-реализация для целей тестирования). C0s>идея в том, что их PR можно достаточно достаточно быстро протолкнуть в базовую ветку, после чего можно параллелить оставшиеся задачи, как оставшиеся низкоуровневые (настоящую реализацию заложенных абстракций), так и высокоуровневые (использование заложенных абстракций).
Этот вариант не решает изначальную проблему.
Кроме того, недостатки:
— низкоуровневый код может быть и так очень простым. Без необходимости дальнейшего упрощения Но всё равно застрянет на ревью.
— а ревью может проходить только раз в неделю. И никакие упрощения его не ускорят.
— базовый код может быть плохо мокаемым, и написать производный не получится.
— родительским PR может быть вообще не какой-то новый код, а какие-то принципиальные изменения — интерфейсы, архитектура. Предлагается зависимый код писать дважды ? Сначала под старый вариант (что не всегда возможно — например нехватка каких-то ключевых моментов), потом, после мержа, под новый.
Здравствуйте, aik, Вы писали:
aik>Стянул низкоуровневый рабочий бранч у коллеги, сделал ребейз своего хлама сверху и копай себе дальше.
Лихо ты всё изменил. Низкоуровневых бранча два.
IID>>Создавать бранч высокоуровневой задачи от бранча низкоуровневой как-то неправильно. Да и невозможно в случае задачи-3, ей нужны обе низкоуровневые задачи одновременно.
aik>Это только если у тебя строго 1 гит репозиторий, и странная религия, не позволяющая тянуть чужие бранчи из неглавного репозитория.
стого 1 гит репозиторий.
IID>>Для случаев II) и III) также непонятно как гарантировать правильную очередность слияний зависимых PR.
aik>Когда отладятся все три бранча, то и влить их в основной по порядку.
Точнее создать ещё 3 пулл-реквеста. И вот их висит уже 5. Кто разрулит порядок ? А где 5, там и 105. С нетривиальными зависимостями друг-от-друга.
Ок, например разруливаем в порядке создания. И ВНЕЗАПНО в низкоуровневом коде (а) нашли какой-то ляп и реквест не прошёл. Где гарантии, что два зависящих от него высоуровневых бранча, не будут смержены, сломав этим билд ?
Здравствуйте, IID, Вы писали:
aik>>Стянул низкоуровневый рабочий бранч у коллеги, сделал ребейз своего хлама сверху и копай себе дальше. IID>Лихо ты всё изменил. Низкоуровневых бранча два.
Да хоть двадцать.
aik>>Это только если у тебя строго 1 гит репозиторий, и странная религия, не позволяющая тянуть чужие бранчи из неглавного репозитория. IID>стого 1 гит репозиторий.
Тогда это гит курильщика, и твоя Проблема не решается средствами гита. Возьми cvs.
IID>>>Для случаев II) и III) также непонятно как гарантировать правильную очередность слияний зависимых PR. aik>>Когда отладятся все три бранча, то и влить их в основной по порядку. IID>Точнее создать ещё 3 пулл-реквеста. И вот их висит уже 5. Кто разрулит порядок ?
Тот, кто делает "git pull", очевидно. Не может разрулить сам — пойдёт да спросит. Странная проблема.
IID>Ок, например разруливаем в порядке создания. И ВНЕЗАПНО в низкоуровневом коде (а) нашли какой-то ляп и реквест не прошёл. Где гарантии, что два зависящих от него высоуровневых бранча, не будут смержены, сломав этим билд ?
Можно сделать мердж всего у себя и проверить. Можно завести бота, который будет запускать сборку ветки с определённым именем в Главном Репозитории.
Здравствуйте, aik, Вы писали:
IID>>Низкоуровневых бранча два.
aik>Да хоть двадцать.
Тогда распиши подробнее. Я не понимаю.
Вот висят у нас две низкоуровневые задачи в своих бранчах на PR.
Мы хотим пилить высокоуровневую задачу в её собственном бранче. Что мы для этого делам ? По-шагам. Условие — все ветки бранчуются от текущего dev.
Здравствуйте, IID, Вы писали:
IID>>>Низкоуровневых бранча два. aik>>Да хоть двадцать. IID>Тогда распиши подробнее. Я не понимаю. IID>Вот висят у нас две низкоуровневые задачи в своих бранчах на PR. IID>Мы хотим пилить высокоуровневую задачу в её собственном бранче. Что мы для этого делам ? По-шагам. Условие — все ветки бранчуются от текущего dev.
Да надо чтоб работнички между собой разговаривали, и всех делов.
У кого зависит работа от остальных — ждут пока зависимости будут минимально готовы чтоб начинать что то делать поверх. Несколько зависимостей? Делаешь текущий локальный бранч на основе "dev", мержишь туда бранчи зависимостей (которые стянул у коллег, а не из главного репо), делаешь своё поверх этого. Кто то зависит от тебя? Довёл ветку до рабочего состояния — push в доступный коллегам репозиторий. Или шарь свой на чтение, пусть оттуда тянут.
Нашлись косяки в чужом? Окей, делаешь новый временный бранч, мержишь туда снова изменённые бранчи зависимостей, ребейзишь свой код поверх новой ветки и копаешь дальше. И так несколько раз. Можете проверять в процессе как оно собирается и не ломает всё прочее, хз что там у вас. У нас есть внутри git, куда можно запихать бранч под заданным именем (понятно, что git push -f), а он его будет собирать и тестить с пачкой конфигов.
Когда всё работает и перестало падать — делаете PR, порядок определяете сами и в этом порядке вливаете в основной бранч. Победа.
IID>Коллеги, поясните пожалуйста, как разруливаются зависимые задачи при использовании PR ?
По опыту, таких проблем обычно не существует. В большинстве случаев, задачи можно делать независимо друг от друга.
Если проект на самой начальной стадии, и не написана даже база (запись в файл), то никаких пулл реквестов не нужно, можно просто "коммитить в мастер".
Если же все же появляется зависимая задача и используются пулл реквесты, можно просто взять бранч коллеги который её реалиует (из центрального репозитория, тот который висит в пулл реквесте), и базировать свою работу на нем. Всё нормально скомбинируется при последующем слиянии.
Копировать файлы коллеги "вручную", реализующие нужную тебе функциональность, ни в коем случае не следует (если ты так сделаешь, они все закофликтятся в твоём мерже). Просто возьми его бранч.
Здравствуйте, IID, Вы писали:
IID>Вот висят у нас две низкоуровневые задачи в своих бранчах на PR. IID>Мы хотим пилить высокоуровневую задачу в её собственном бранче. Что мы для этого делам ?
Делаешь свой бранч от dev, мержишь локально у себя обе низкоуровневые ветки (висящие в пулл реквестах) в этот бранч, делаешь свою задачу в этом бранче, создаёшь пулл реквест в dev.
IID>По-шагам. Условие — все ветки бранчуются от текущего dev.
Это условие вообще-то глупое. Не нужно все ветки бранчевать от dev, это ничего не дает и не меняет.
Центральный репозиторий один, да, но веток-то в нем может быть много. Откуда делаются пулл реквесты-то? Из веток в центральном репозитории. То есть, все изменения в центральном репозитории уже присутствуют, и их оттуда можно взять, просто они пока не в ветке dev, а в ветках разработчиков.
Здравствуйте, bnk, Вы писали:
bnk>Делаешь свой бранч от dev, мержишь локально у себя обе низкоуровневые ветки (висящие в пулл реквестах) в этот бранч, делаешь свою задачу в этом бранче, создаёшь пулл реквест в dev.
Здравствуйте, IID, Вы писали:
bnk>>Делаешь свой бранч от dev, мержишь локально у себя обе низкоуровневые ветки (висящие в пулл реквестах) в этот бранч, делаешь свою задачу в этом бранче, создаёшь пулл реквест в dev.
IID>Это вариант III) стартового сообщения.
Здравствуйте, bnk, Вы писали:
bnk>Если проект на самой начальной стадии, и не написана даже база (запись в файл), то никаких пулл реквестов не нужно, можно просто "коммитить в мастер".
Не важно на какой стадии проект. Крупные изменения могут вызвать такие же зависимости, как в стартовом сообщении.
bnk>Копировать файлы коллеги "вручную", реализующие нужную тебе функциональность, ни в коем случае не следует (если ты так сделаешь, они все закофликтятся в твоём мерже). Просто возьми его бранч.
Ну т.е. смержи себе все бранчи, которые в PR и которые нужны.
СОбс-но в начале работы каждый делал себе свою версию dev, и мержил туда из аналогичных веток коллег.
Но один из разработчиков стал ругаться, что история теперь выглядит "кучеряво" и ничего в ней не понять. Поэтому с его инициативы перешли на систему "бранч из dev" -> "фича" -> "PR в dev".
Сам я в гите новичок, и опасаюсь что слияния из висящих PR будут восприняты таким же образом, как и кросс-мержинг между ветками.
Здравствуйте, IID, Вы писали:
IID>СОбс-но в начале работы каждый делал себе свою версию dev, и мержил туда из аналогичных веток коллег. IID>Но один из разработчиков стал ругаться, что история теперь выглядит "кучеряво" и ничего в ней не понять. Поэтому с его инициативы перешли на систему "бранч из dev" -> "фича" -> "PR в dev".
Для более красивой истории в git есть rebase, если его делать перед пулл реквестом... Тогда история в dev будет (почти) линейной.
Здравствуйте, 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 или оно в отдельной ветке будет стоять в очереди ждать ревью — лишь бы было починено), или временно починить самому, если совсем невтерпеж. Но чужие лучше подождать. Типа, фича "вывод числа из файла на экран" зависит от фич "работа с экраном" и "работа с файлом", они пишутся другими разработчиками и еще не готовы.
Вроде на все вопросы ответил. Спрашивай, если что.
Очень рекомендую почитать про гит вот эту книгу, на русском там тоже есть. Сразу многое станет понятно.
Здравствуйте, IID, Вы писали:
IID>Коллеги, поясните пожалуйста, как разруливаются зависимые задачи при использовании PR ? IID>III) Бранчеваться от "старого" dev, мержить "подвисшие" PR задачи в этот бранч ?
Ну да, как бы уже ответили на твой вопрос, что это самый естественный способ.
IID>Для случаев II) и III) также непонятно как гарантировать правильную очередность слияний зависимых PR.
Самое страшное что может произойти — это если замержат высокоуровневый PR до того, как закончен ревью низкоуровневого PR, но тогда просто последующие модификации процесса ревью будут влиты потом, т.е. в мастер попадёт не доконца отревьювленный код. Тут уже вопрос во внимательности ревьюверов.
А вообще говоря, я считаю что модель PR хороша для публичной разработки, когда толпой пилят что-то независимо и спонтанно. Она плохо применима в условиях enterprise проектов, плохо, что она стала популярной. Модель changesets в gerrit мне нравится больше. Скажем, там можно явно иметь dependencies, притом даже между независимыми репами и они будут разрешены для мержа только в заданном порядке. https://www.mediawiki.org/wiki/Gerrit/Advanced_usage#Create_a_dependency
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
IID>Коллеги, поясните пожалуйста, как разруливаются зависимые задачи при использовании PR ? IID>Поясню на примере. Есть 3 высокоуровневые задачи: IID>1) вывести на экран число 42 IID>2) прочитать информацию из файла и записать в другой файл IID>3) прочитать информацию из файла и вывести её на экран.
IID>Для реализации этих задач создаём базис, 2 низкоуровневые задачи IID>а) абстракция вывода на экран IID>б) аобстракция работы с файлами
1, 2 и 3 явно зависят от а и б. Это вопрос планирования, а не git. Согласуйте интерфейсы, сделайте а и б в минимально необходимом объёме, а потом приступайте к 1,2,3
Если никак, то выше уже описали варианты. Можно ещё базовые вещи в либу отдельную выделить, если они используются больше чем в одном проекте. Сделать версионность и всё такое.
Здравствуйте, IID, Вы писали:
IID>СОбс-но в начале работы каждый делал себе свою версию dev, и мержил туда из аналогичных веток коллег. IID>Но один из разработчиков стал ругаться, что история теперь выглядит "кучеряво" и ничего в ней не понять. Поэтому с его инициативы перешли на систему "бранч из dev" -> "фича" -> "PR в dev".
Что, блин, за фапанье такое на исторю? Не первый раз сталкиваюсь. Ну делайте ребейз вместо мержа или сквош при мерже PR.
Здравствуйте, IID, Вы писали:
IID>Ну т.е. смержи себе все бранчи, которые в PR и которые нужны.
Да, надо стянуть все коммиты которые нужны для работы в свой бранч.
IID>Но один из разработчиков стал ругаться, что история теперь выглядит "кучеряво" и ничего в ней не понять. Поэтому с его инициативы перешли на систему "бранч из dev" -> "фича" -> "PR в dev".
Это ключевой момент. Не важно как начинается разработка фичи, важно как выглядят история после её завершения. Надо почитать про типичные сценарии разработки в git и выбрать то, что вам по душе. Например тут: https://www.endpoint.com/blog/2014/05/02/git-workflows-that-work .
IID>Сам я в гите новичок, и опасаюсь что слияния из висящих PR будут восприняты таким же образом, как и кросс-мержинг между ветками.
Гит хорош тем, что можно легко и относительно безболезненно переносить свои изменения в дереве коммитов. Наример начать разработку из какой-то ветки, а перед созданием PR отребейзить свои коммиты на актуальную версию dev.
