Работа с Git#

Git — это система контроля версий. Она хранит текущую версию кода, а также все изменения, которые вносили разработчики.

Основные понятия#

Сущности#

Репозиторий: Это место, где хранится проект. Код прикладных модулей хранится в удалённом репозитории на GitLab. У каждого разработчика на ПК есть локальный репозиторий - копия удалённого. Разработчик вносит изменения в код на своём ПК и, выполнив задачу, отправляет изменения на удалённый репозиторий. Остальные программисты периодически обновляют свои локальные репозитории, чтобы иметь последнюю версию кода. Это можно сделать с помощью команды pull или с помощью gsf-cli.

Коммит (commit): Это сохранение изменений в репозитории. Коммит - это конкретное осмысленное изменение: добавлен класс, исправлена ошибка, переделана функция и т.д. Git позволяет восстановить исходный код проекта на момент любого коммита. О них можно думать как о «точках сохранения» исходного кода.

Ветка (branch): Ветка представляет собой цепь коммитов. От основной ветки можно отводить новые, создавая отдельные линии разработки. Ветки позволяют работать над новыми функциями и исправлениями, не затрагивая основную версию проекта. Когда новый функционал готов в отдельной ветке, можно применить проделанные изменения к основной ветке. Эта операция называется merge.

Запрос на слияние (merge request): Когда в отельной ветке готов новый функционал, он не включается в основную ветку автоматически. Вместо этого автор изменений создаёт запрос на слияние, который должен быть одобрен для того, чтобы ветки можно было объединить. Этот процесс проверки кода называется код-ревью.

Тег (tag): Тег используется для маркировки определённых точек в истории коммитов. Обычно теги применяются для обозначения релизов (например, 1.0.161). Все версии модулей компилируются и хранятся в облаке - такие размещённые в облаке сборки называются артефактами. В итоге для того, чтобы поменять версию модуля, которую импортирует проект, достаточно поменять номер версии в конфиге.

Ишью (issue): предложение на внутреннем форуме проекта в гитлабе. Там можно указывать на ошибки, предлагать и обсуждать идеи. В нашей компании ошибки указывают не там - вместо этого создают ДП в системе Support, не имеющей отношения к GitLab.

Роли#

У аккаунтов в GitLab могут быть разные роли в разных репозиториях. У разработчика один аккаунт на весь GitLab, при этом он может быть мейнтейнером в одном модуле и рядовым разработчиком - в другом.

Девелопер (developer): программист, работаюший над проектом. Может создавать новые коммиты, ветки и merge request’ы.

Мейнтейнер (maintainer): Мейнтейнер отвечает за управление репозиторием. Он проводит код-ревью, принимает или отклоняет запросы на слияние.

Основные команды Git#

В IDEA во вкладке Git или VCS есть три основные команды - Update (она же Pull), Commit и Push

Обновление проекта#

Используется для того, чтобы обновить локальный репозиторий последними изменениями. Применяются коммиты, созданные другими разработчиками в той же ветке.

Коммит#

Разработчик может редактировать код у себя на ПК как угодно - изменения не будут зафиксированы, пока он это не сделает с помощью команды commit. Её смысл - сохранить рабочую версию кода, в которой реализован новый функционал или исправлена ошибка. Когда разработчик доволен написанным кодом, он нажимает commit и отмечает изменённые файлы. Очень важно дать коммиту понятное имя, потому что с ним будут иметь дело другие программисты.

Названия коммитов#

Общий формат коммита - Label(Scopes): Subject [#issue Issue]

Label - это одно из:

  • feat, для добавлений нового функционала

  • fix, для исправлений ошибок

  • hotfix для быстрого исправления недавней ошибки

  • test для новых тестов

  • refactor для улучшений кода без изменений функциональности

  • docs для правок документации

  • style для форматирования, приведения к CodeStyle

  • chore для случаев, когда не подходят остальные ярлыки.

Scopes - модул(и), в которые вносят изменения.

Subject - короткое описание изменений. Оно начинается с заглавной буквы и и совершенного глагола неопределённой формы - Изменить, Исправить, Реализовать.

Issue - номер задачи, при наличии. Обычно это номер ДП.

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

fix(rpl): Убрать поле "Источник" у входящих сообщений интеграции с превышенным числом ошибок #issue 182831T

Новосозданный коммит существует только в локальном репозитории. Чтобы отправить изменения на GitLab, используется команда Push.

Push#

Эта команда отправляет коммиты на удалённый репозиторий.

Ветки#

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

В IDEA меню управления ветками расположено справа от выбора проекта:

Переключаться на другую ветку можно с помощью операции checkout. При этом код приложения меняется на версию в ветке. Если в ветке, с которой переключаются, были незакоммиченные изменения, они пропадут; нужно их закоммитить или как-то ещё сохранить.

Создание веток#

Новую ветку можно создать в меню управления ветками, с помощью New Branch. Обычно новая ветка должна отходить от основной ветки - main, поэтому перед созданием новой нужно переключииться на main.

Названия веток#

Общая форма названия ветки - Label/Scope [Issue].

Label, Scope и Issue - как в названиях коммитов. Например,

Каждый модуль - это отдельный git репозиторий, ветку нужно создавать именно в том модуле, который будут править:

Merge request#

Когда функция готова в своей отдельной ветке удалённого репозитория, создают запрос на слияние веток – merge request. Ответственный за модуль разработчик с ролью мейнтейнера изучает предложенные изменения, комментирует их и указывает на ошибки и недоработки. Создатель реквеста продолжает делать коммиты в ту же ветку, пока проблемы не будут решены. После этого происходит слияние веток (merge), и изменения попадают в главную ветку main.

Merge request’ы можно делать из IDEA, но удобнее через GitLab. После пуша в новую ветку GitLab автоматически предлагает создать merge request на главной странице модуля:

Можно указать ревьюера - пользователя, без чьего подтверждения нельзя будет сделать merge. Иногда он проставляется автоматически, как /reviewer на скрине. Могут быть настроены несколько шаблонов (template) merge request’ов.

В общем случае назначать ревьюера необязательно - мейнтейнер и так видит все мёрдж реквесты в модуле.

Ревьюер либо одобрит (Approve) merge request, либо укажет на ошибки, которые нужно исправить. Нужно исправлять ошибки, коммитить и пушить в ту же ветку, пока реквест не получит approval. После этого можно в меню реквеста жать merge.

Порядок выполнения ДП#

  • Создать новую ветку под ДП или перейти в существующую

  • Написать код

  • commit с указанием сути задачи и номером ДП

  • push

  • merge request