Мы придерживаемся одного из самых распространённых подходов работы с гитом при котором бранчи являются расходником.

System branches:

• master -- релизы. Обновляется очень редко при достижении майлстоуна.
• demo -- protected. обновляется не реже чем раз в 2 недели. Из этой ветки наливается терминал. Она же считается наиболее актуальной кодовой базой.
• public -- ответственна за работу http://doc.quokka.pub
• test -- дополнительная ветка для наливки терминала. Служит для тестирования кода на реальном устройстве.

1. На каждую задачу в трекере заводится отдельный бранч.

Такой подход позволяет изолировать задачу, сфокусироваться на ней и иметь возможность в любой момент отложить её решение без вреда для остального проекта. Название ветки выглядит как CORE-216 и соответствует имени задачи в трекере.

2. У каждого разработчика есть своя ветка-песочница.

После выполненной работы над задачей -- разработчик забирает в свою ветку изменения из demo и из ветки с задачей. В своей ветке можно проводить любые эксперименты и тестировать интеграцию новой фичи в проект.

3. После завершения задачи создаётся mёrge request ветки разработчика c веткой demo.

На этой стадии осуществляется code review написанного кода и если всё хорошо -- код попадает в ветку demo.

Мини-гайд по интеграции системы контроля версий с трэкером.

Ссылка на полную документацию

Все команды выполняются из коммит-сообщения.

Просто референс: Тело сообщения #<ID задачи>

Референс с комментом в таске: Тело сообщения #<ID задачи> comment Комментарий задачи в YouTrack

Манипулировать состоянием таска (например перевести в "В обработке"): Тело сообщения #<ID задачи> In Progress

Нюанс: Логин/почта пользователя должны совпадать в YouTrack и GitLab, иначе YouTrack не сможет распознать автора коммита.