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

![](../img//git/basic-commands.png)

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

### Коммит
Разработчик может редактировать код у себя на ПК как угодно - изменения не будут зафиксированы, пока он это не сделает
с помощью команды 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 меню управления ветками расположено справа от выбора проекта:

![](../img//git/branch-menu.png)

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

![](../img//git/checkout.png)

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


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

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

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

![](../img//git/branch-name-example.png)


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

![](../img//git/module-spec-branch.png)

## Merge request

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

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

![](../img//git/merge-request.png)

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

![](../img//git/MR-template.png)

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

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

## Порядок выполнения ДП
* Создать новую ветку под ДП или перейти в существующую
* Написать код
* commit с указанием сути задачи и номером ДП
* push
* merge request