Здравствуйте, bnk, Вы писали:
IID>>По-шагам. Условие — все ветки бранчуются от текущего dev.
bnk>Это условие вообще-то глупое. Не нужно все ветки бранчевать от dev, это ничего не дает и не меняет.
Это условие очень хорошее.
Потому что когда людей больше некоторого количества, без этого история веток выглядит как кастрюля макарон — фиг поймешь что-откуда-куда. Вернее, поймешь если надо, но сложно и надо напрягаться — проблема на ровном месте.
У нас было обязательное требование — перед вливанием в dev делать rebase на dev, это как раз визуально выглядит как "все ветки бранчуются от текущего dev".
Скорей всего у IID как раз это и есть.
bnk>Центральный репозиторий один, да, но веток-то в нем может быть много. Откуда делаются пулл реквесты-то? Из веток в центральном репозитории. То есть, все изменения в центральном репозитории уже присутствуют, и их оттуда можно взять, просто они пока не в ветке dev, а в ветках разработчиков.
Когда много людей и еще больше веток, если не ребейзить, то потом сложно понять, где кто что сделал.
Здравствуйте, antonio_v_krasnom, Вы писали:
__>У нас было обязательное требование — перед вливанием в dev делать rebase на dev, это как раз визуально выглядит как "все ветки бранчуются от текущего dev". __>Скорей всего у IID как раз это и есть.
С этим никто и не спорит — хорошая практика, годная
Но речь именно про rebase на dev перед созданием PR, а не о бранчевании от dev в буквальном смысле этого слова.
(я так понял, что в конторе ТС придумали делать именно так — бранчеваться исключительно от dev, иначе откуда бы вопросы)
Здравствуйте, bnk, Вы писали:
__>>У нас было обязательное требование — перед вливанием в dev делать rebase на dev, это как раз визуально выглядит как "все ветки бранчуются от текущего dev". __>>Скорей всего у IID как раз это и есть.
bnk>С этим никто и не спорит — хорошая практика, годная bnk>Но речь именно про rebase на dev перед созданием PR, а не о бранчевании от dev в буквальном смысле этого слова.
Вначале можно бранчеваться хоть от черта лысого — просто потом сложнее ребейз будет делать, если совсем не оттуда ответвишься (в наихудшем случае и вовсе придется cherry-pick'ом переносить изменения, если он не пройдет).
А после того, как он (ребейз) сделан, ветка выглядит как только что отбранчеванная от текущей dev. А если быть точнее, не просто выглядит, а является (ты не отличишь, я сразу от свежего dev бранчевался, или от чего угодно и потом ребейзился).
bnk>(я так понял, что в конторе ТС придумали делать именно так — бранчеваться исключительно от dev, иначе откуда бы вопросы)
А я так понял, что там требование, чтоб она была отребейжена на dev перед созданием PR (читай только что ответвлена от dev).
Так что никакого противоречия нет — это эквиваленты.
НС>Что, блин, за фапанье такое на исторю? Не первый раз сталкиваюсь.
И всё-таки разумное зерно в этом есть. Если не смотреть историю — то да, тогда всё равно, как она выглядит. Если смотреть — то, глядя на граф с 3-5-10 ветками, уже сложно понять, что откуда пришло и в каком порядке.
НС>Ну делайте ребейз вместо мержа или сквош при мерже PR.
Здравствуйте, IID, Вы писали:
IID>Кроме того, недостатки: IID>- низкоуровневый код может быть и так очень простым. Без необходимости дальнейшего упрощения Но всё равно застрянет на ревью. IID>- а ревью может проходить только раз в неделю. И никакие упрощения его не ускорят.
Так заведите правило, что ключевые разработчики имеют право пихать тривиальные коммиты без ревью. И отмените правило, что ревью проходит только раз в неделю.
Вообще, на то они и правила, чтобы их менять, если жизнь в них не укладывается.
IID>Коллеги, поясните пожалуйста, как разруливаются зависимые задачи при использовании PR ?
IID>Поясню на примере. Есть 3 высокоуровневые задачи: IID>1) вывести на экран число 42 IID>2) прочитать информацию из файла и записать в другой файл IID>3) прочитать информацию из файла и вывести её на экран.
IID>Для реализации этих задач создаём базис, 2 низкоуровневые задачи IID>а) абстракция вывода на экран IID>б) аобстракция работы с файлами
У вас скорее вопрос менеджмента, а не технический.
От каких требований вы отталкивались, когда придумали такой бизнес процесс?
Разработчикам новую реализацию необходимо писать в тесном взаимодействии. На первой итерации вы не получите 100% готовых компонентов и при изменении базовых абстракций придется менять их использование.
Можно сделать так:
делаете ветку с мастера new_feature — изоляция кода.
разработчики создают пулреквесты в new_feature — нет необходимости потом смотреть большой кусок кода в new_feature весь код просмотрен
регулярный rebase мастера — при обратном мерже не будет конфликта.
Потом, как будут готовы и закончены асбтракции, можно их вытаскивать в модули, библиотеки, релизить отдельными циклами, но это потом, сначала надо получить рабочую версию
IID>Коллеги, поясните пожалуйста, как разруливаются зависимые задачи при использовании PR ?
Кажется команда борется сама с собой.
IID>Реализуем низкоуровневые в своих ветках, пушим, создаём PR.
Отлично!
IID>И... наступает ступор.
Нет — просто берём другие задачи и делаем их пока "ждём".
IID>Т.к. пока не пройдёт ревью и они не попадут в dev — мы не можем приступать к реализации ни одной из высокоуровнеых задач!
Если это прям такие важные задачи, можно же просто попросить коллег сделать ревью поскорее.
IID>Создавать бранч высокоуровневой задачи от бранча низкоуровневой как-то неправильно. Да и невозможно в случае задачи-3, ей нужны обе низкоуровневые задачи одновременно.
IID>Предположим, других задач сейчас больше нет.
Да ладно — ни одного бага в бэклоге? Мне кажется во всём этом вопросе не так много гита, сколько планирования.
IID>Что делать ? IID>I) Сидеть сложа руки, пока не пройдёт ревью и dev станет актуальным ?
Вот же — можно попросить поскорее проревьюить. Но вообще, конечно, лучше бы чтобы процесс разработки учитывал это самое "поскорее", чтобы просить не нужно было.
IID>II) Сделать высокоуровневые задачи в своей локальной ветке. Затем перенести вручную файлы высокоуровневой задачи "на авось", в её бранч от старого dev. В таком случае проверить этот ручной перенос не получится. Даже простой build, не говоря про какие-то тесты. IID>III) Бранчеваться от "старого" dev, мержить "подвисшие" PR задачи в этот бранч ?
IID>Для случаев II) и III) также непонятно как гарантировать правильную очередность слияний зависимых PR.
Мне кажется проблема с процессами. Делать надо так, как комфортно. Если процессы мешают, стоит поменять либо их, либо если невозможно — поменять работу.
