diff --git a/development-guidelines.md b/development-guidelines.md index 574d24e..906793b 100644 --- a/development-guidelines.md +++ b/development-guidelines.md @@ -587,6 +587,24 @@ patch series на ревью кода лидом проекта. Требова Такая последовательность требуется, чтобы можно было пользоваться `git bisect`. + +## TLDR действия после bugfix в рабочей ветке + +Работа ведется в 3х ветких master, dev и рабочая. Причем master!=dev и в мастер нельзя лить комиты, только ветки. Подробнее вро работу с ветками можно прочесть [Ветки](#Ветки) Имена master и dev уточняйте. + + +рабочая ветка никому кроме разработчика не нужна, для ревью следует создать ветку вида `//` +Ветка для ревью должна быть создана от dev ветки, для того чтобы ревьюер \ тестер могли сразу проверить изменения. + +При отправки кода на ревью, нужно: +* выбрать в ветку на ревью - только "нужные" изменения через merge+squash ветки разработчика, если изменения логически соответвуют одому комиту или же через cherry pick комитов из ветки разработчика, при этом сами комиты должны быть оформленны и содержать сообщения согласно [Коммиты](#Коммиты) +* запушить ветку для ревью +* отписать в тикет в Redmine о ветке, перевести Assignee на ревьюера, сменить статус тикета (On Blocking/Nonblocking Review) + + +После ревью, тикет Redmine вернется разработчику обратно: +* если необходимы дальнейшие исправления - то код, для повторной отправки на ревью, должен заливатся в новую ветку с суффиксом итерации `...._v`. Как например - начальная ветка для ревью `dev1/7/fix_of_all_around`, а ветка с дальнейшими исправлениями будет названа как `dev1/7/fix_of_all_around_v2` +* если изменения должны быть опубликованы, то необходимио создать ветку уже от master, с таким же именем и суфиксом новой итерации. В эту ветку сделать rebase своих изменений из ветки одобренной на ревью. Можно использовать команду ```git rebase --onto master_v1 dev_v3 dev1/7/fix_of_all_around_v3```. После чего запушить ветку в мастер # Про комментарии в коде (TODO)