Содержание

• Git-Flow
  • Основные правила
  • Работа с коммитами
  • Работа с ветками
    • develop
    • features
    • refactoring
    • releases
    • bugs
  • Создание мёрж реквестов
  • Исправление замечаий по код ревью

Git-Flow

Основные правила

Отключить fast-forward merge

При мёрже веток в обязательном порядке должен быть отключен fast-forward merge При мерже через командную строку нужно добавить ключ --no-ff, либо при мёрже через GUI, fast-forward merge нужно отключить в настройках используемого вами приложения.

Проверьте что вы коммитите

Перед коммитом проверьте какие изменеия лежат в stage и не будут ли закоммичены лишние файлы и изменения.

Не мёржить родительскую ветку в дочернюю

При необходимости реализации вашей функциональности на основе изменений в родительской ветке используйте rebase. Старайтесь не мёржить родительскую ветку в ту, в которой вы сейчас работаете. Это услжняет дальнейшую работу с историей изменений. Используйте merge только при крайней необходимости, когда конфликтов слишком много.

Перед мёрж реквестом "причесать" коммиты

Поправьте историю коммитов в вашей ветке с помощью interactive rebase. Никому не хочется смотреть на идущие подряд коммиты с названиями "фикс", "фикс фикса", "не получилось" и так далее.

Работа с коммитами

Каждый коммит должен содержать в себе логически законченное изменение. В него не должны попадать какие либо другие изменения.
Комментарий к коммиту должен быть написан на русском языке, содержать ID в квадратных скобках, название задачи и краткое описание изменения, отделённое пустой строкой.

Пример комментария:

[EW_IOS-98] требуется собрать приложение с использованием IBM Maas 360 SDK 2.95

- Обновил структуру и настройки проекта
- Обновил фреймворк MaaS

Работа с ветками

Важно: git плохо работает с нашими буквами "й" и "ё", следует избегать их использования в именах веток.

develop

Основная ветка разработки. В неё мёржатся ветки фич, рефакторингов и багов после тестирования.

features/<feature_id_in_issue_tracker>_<feature_name_in_issue_tracker>

Создаётся под конкретную задачу на разработку фичи в Джире.

Пример:

features/EW_IOS-98_Реализовать_независимую_отправку_и_получение_данных_с_сервера

Создаётся из develop, мёржится в develop.

После завершения работы над задачей необходимо создать мёрж реквест из ветки с фичей в ветку develop.
Ветка мёржится после прохождения Code Review и цикла тестирования.

refactoring/<refactoring_name>

Создаётся под изменение кода без расширения функциональности.

Создаётся из develop, мёржится в develop

releases/release-<release_version>

В этой ветке стабилизируется версия, которая в итоге будет передана Заказчику.
В неё мёржится только багфикс.

Создаётся из develop, мёржится в develop и master

bugs/<bug_id_in_issue_tracker>_<bug_name_in_issue_tracker>

Создаётся и мёржится из любого типа ветки. Зависит от того, куда необходимо внести исправление. Уточнить у аналитика.

Примеры:

bugs/EW_IOS-98_исправить_падение

После завершения работы над задачей необходимо создать мёрж реквест из ветки с багом в ветку, из которой была создана ветка с багом.
Ветка мёржится после прохождения Code Review и цикла тестирования.

Создание мёрж реквестов

Заголовок должен содержать ID в квадратных скобках и название задачи.
При создании мёрж реквеста должна быть включена опция "Delete source branch when merge request is accepted."

Исправление замечаий по код ревью

После исправления необходимо отписаться в замечани. Это требуется, чтобы автор замечания увидел, что оно было исправлено и проверил корректность исправления. Достаточно написать "Готово", или "✅".