Home

При создании pull request создаем его с целевой веткой develop. Перед созданием pull request в последнем коммите ветки (а в идеале в каждом) необходимо вызвать

dart format

для автоматического форматирования кода (либо вызвать соответствующую функцию IDE. IMHO команда быстрее и проще :) ), а также

flutter analyze

для проверки кода линтером. Если есть проблемы - исправить. Pull request'ы с плохим кодом не принимаем :P

Правила именования веток

Ветки для фич именуем следующим образом:

feature/{number} (вместо {number} число, id issue, который соответствует данной задаче)

Для багфиксов, соответственно:

bugfix/{number}

Для небольших изменений (задачи minorchange):

minorchange/{number}

Для рефакторинга:

refactor/{number}

Для изменений в конфигах проекта, файлах сборки Android и iOS:

config/{number}

или

config/{short-name}

где {short-name} - короткое название ветки, описывающее её суть, слова разделены дефисом. Применять, если нет задачи на такие изменения.

Изменения CI коммитятся напрямую в main ветку, в обход правил, поскольку нет возможности их тестировать, и на каждую поправленную букву делать PR это слишком затратно.

Flow для релиза:

1. Создание плана через milestones

2. Выполнение задач:

2.1. Создаём ветку с номером задачи и типом согласно правилам

2.2. Создаём pull request в ветку develop. Название в идеале должно содержать краткое причастие вместо глагола прошедшего времени ('сделал' -> 'сделано'), либо существительное, описывающее непосредственный функционал (например, "вьюмодель экрана ленты")

2.3. После слияния ветка удаляется и в develop остаётся единственный коммит.

2.4. Первый pull request после релиза должен изменять версию

3. Когда выполнено достаточно задач для релиза, выполняем слияние в main без merge коммита. Вешаем тег релиза на ветку main.

Чтобы не забывать про changelog в конце релиза, нужно писать его в каждом pull request'е, который добавляет функционал. Если задача разделена на несколько, то только последняя подзадача должна вписывать что-то в changelog.