Сообщение Re: пулл-реквесты в git от 06.02.2019 12:04
Изменено 06.02.2019 14:31 antonio_v_krasnom
Re: пулл-реквесты в git
Здравствуйте, 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>Коллеги, поясните пожалуйста, как разруливаются зависимые задачи при использовании 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 или оно в отдельной ветке будет стоять в очереди ждать ревью — лишь бы было починено), или временно починить самому, если совсем невтерпеж. Но чужие лучше подождать. Типа, фича "вывод числа из файла на экран" зависит от фич "работа с экраном" и "работа с файлом", они пишутся другими разработчиками и еще не готовы.
Вроде на все вопросы ответил. Спрашивай, если что.
Очень рекомендую почитать про гит вот эту книгу, на русском там тоже есть. Сразу многое станет понятно.
Re: пулл-реквесты в git
Здравствуйте, 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>Коллеги, поясните пожалуйста, как разруливаются зависимые задачи при использовании 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 или оно в отдельной ветке будет стоять в очереди ждать ревью — лишь бы было починено), или временно починить самому, если совсем невтерпеж. Но чужие лучше подождать. Типа, фича "вывод числа из файла на экран" зависит от фич "работа с экраном" и "работа с файлом", они пишутся другими разработчиками и еще не готовы.
Вроде на все вопросы ответил. Спрашивай, если что.
Очень рекомендую почитать про гит вот эту книгу, на русском там тоже есть. Сразу многое станет понятно.