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.

Планирование, GitHub Milestones:

• Основными единицами планирования у нас являются задачи issues, которые объединены в группы по релизам: milestones.
• Каждый milestone должен содержать некоторое количество задач и быть распределён на относительно небольшой срок (например, месяц).
• В описании должны быть выписаны цели, которые должны быть выполнены в рамках периода.
• У каждой задачи должен быть выбран priority (приоритет) и effort (трудность). Для багов effort необязателен
• Если цели были достигнуты быстро, можно добавлять другие задачи в milestone
• В идеале сроки выполнения milestone переноситься не должны и невыполненные задачи нужно выносить, всё равно делая релиз. Однако пустой релиз делать смысла нет, поэтому в каждом milestone должны быть обязательные для выполнения задачи, из-за которых можно перенести релиз. Они помечены меткой required.

Для удобства просмотра задач текущего релиза есть Projects и сама страница Milestones.

После каждого релиза незаконченные задачи нужно выносить в бэклог (т.е. снимать у них пометку законченного milestone), а все выполненные задачи из этого релиза отправлять в архив на странице Project, чтобы не засоряли вид :)