Работа с 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.

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

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

Group - Наименование группы веток:

  • wip/ - Works in progress. Что то долгое, что не известно когда завершиться но явно не скоро. Для больших фич. Пример: wip/feat/config-manager-203636T

  • iss/ - Для мало-живущих веток на определенную задачу. Пример: iss/fix/db-generator-update-class-exist-field-210782T

  • rc/ - Для веток, с решением конфликтов, от которых будет создан МР в релизную ветку. Пример: rc/fix/db-generator-update-class-exist-field-210782T

  • junk/ - (Барахло). Для экспериментов. После окончания экспериментов обязательно удаляется. Пример: junk/test/update-sbt-version

  • usr/<user_name>/ - Для частных пользовательских экспериментов. Пример: usr/ya.ryazanov/test/java-21-support

[SubGroup] - Необязательная подгруппа. К примеру: junk/wip/test/stress-testing, где wip - это [SubGroup].

Label и 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