# Работа с системами контроля версий

# Описание

VCS - система контроля версий. Стандартом в индустрии является Git, иногда встречается Mercurial и SVN, и очень редко другие. Умение грамотно работать с VCS позволяет:

Оперативно исправлять критические баги
Отслеживать вклад разработчиков в продукт
Контролировать качество кода

# Почему ветка важна?

Современные VCS позволяют:

работать одновременно над одним или разными частями файлов
оперативно синхронизировать кодовую базу
иметь несколько вариантов состояний кодовой базы в разных ветках
разрешать конфликты изменений
просматривать историю изменений конкретных файлов или фрагментов кода
собирать статистику по разработчикам

# Что будет, если её не делать?

Низкое качество кодовой базы
Невозможность быстро решать критические проблемы

# На кого может быть делегирована?

Умение работать с VCS на продвинутом уровне может быть делегировано на техлида или старших разработчиков.

# Практика

# Навыки работы с Git

Для комфортной разработки и взаимодействия в команде каждый разработчик должен уметь:

Клонировать репозиторий
Создавать ветки
Переключаться между ветками
Делать коммиты
Делать fetch, pull и push
Делать слияния веток
Уметь разрешать конфликты при merge
Уметь создавать Pull (Merge) Request

Один из опытных разработчиков, техлид или тимлид должны дополнительно уметь:

Делать rebase
Делать force push
Работать с тегами
Настраивать precommit хуки
Настраивать конфиг git
Работать со stash и знать для чего это необходимо

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

В команде должно быть соглашение о наименовании коммитов
Все члены команды должны этому соглашению следовать

# Пример соглашения

Все коммиты пишутся на русском языке
Все коммиты должны иметь следующий формат: <номер задачи> <глагол> <субъект> <детали>` Пример: JIRA-123 Изменил цвет кнопки "Сохранить" на красный
Допустимо писать подробности коммита в произвольной форме отступив 1 строку от заголовка
Недопустимо делать подряд несколько коммитов с одинаковой подписью
Название коммита должно показывать бизнес изменения, если они были, а не изменения в кодовой базе
В коммитах необходимо использовать термины из словаря проекта.

# Хорошо

JIRA-123 Изменил цвет кнопки "Сохранить" на красный

JIRA-123 Исправил ошибку в сообщении при ошибке авторизации

JIRA-123 Сверстал модальное окно подписки на новости сервиса

JIRA-123 Сделал обводку в информационной модалке

# Плохо

fix

Отрефакторил код

Исправил мелкие баги

Добавил border: 1px в MessagePopup

# Почему это важно?

Облегчается поиск по изменениям
Появляется дополнительная документация
Легко найти ответ на вопросы:
- Зачем это сделано?
- Когда это сделано?
- Ошибка это или требование?
- В рамках какой задачи это сделано?
- Кем это сделано?
- Можно ли это отрефакторить?
- Устарел ли это код?
Можно быстро формировать отчёты (ReleaseNotes)
Легко понимать кто и что сделал за определённый промежуток времени

# Консультации

Telegram-чат TL Bootcamp

# Теория

# Способы прокачки

# Методологии