Переключиться на новую ветку, например alex (пока разработчиков сервиса мало, достаточно одной постоянной
персональной ветки)
Внести нужное изменение
Запустить линтинг (проверить, что код соответствует стандартам проекта) с помощью make lint
Если линтинг не прошёл — устранить изменения, в терминале явным образом указывается в какой строке какого файла
проблемы
Запустить тесты (проверить, что изменения не сломали ожидаемое поведение сервиса) с помощью make test
Если тесты не прошли — по сообщениям ошибок в терминале внести изменения в код, если тесты верны, либо поправить
тесты, если ожидания тестов неактуальны
Сделать коммит,
в тексте коммита важно указать краткое описание изменений (на английском или на русском — как предпочтительнее)
В будущем может появиться возможность интегрировать Gitlab и Yandex.Tracker и в таком случае можно будет смотреть
связанные коммиты для задачи и связанные задачи для pull-request-а
Создать в Gitlab merge request
(по историческим причинам иногда их называют pull request)
Создать MR (merge request) нужно из текущей ветки (например, alex) в основную ветку master
Смысл MR в том, чтобы изменения не появились в ветке master непросмотренными — MR отражает список предлагаемых
изменений для основной ветке, которые могут посмотреть другие разработчики, написать комментарии и принять (approve)
или отклонить (decline) изменения
По обстоятельствам и здравому смыслу указать reviewer-а
В Gitlab после создания MR-а запускаются билды на ветку, в которых постепенно отрабатывают шаги build, lint, test
Если билды упали — нужно по сообщениям ошибок понять причину падения и устранить её (чаще всего упавший билд говорит
скорее о забытом локальном запуске линтинга или тестов после внесения изменений)
Когда все билды пройдут, MR можно будет слить
Важно, что после слияния уже на ветке master запускается тот же набор билдов и один дополнительный — deploy
Этот билд загружает собранный docker-образ контейнера сервиса с актуальной веткой master в Docker Registry staging-а