С 14 по 27 июня пройдет онлайн-конференция для тимлидов Podlodka Teamlead Crew!

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

# Описание

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

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

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

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

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

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

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

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

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

# Практика

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

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

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

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

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

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

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

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

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

# Хорошо

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

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

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

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

# Плохо

fix

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

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

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

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

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

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

# Теория

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

  1. Pro Git book
  2. Скринкаст по Git
  3. Игра в гит

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

# GitHub-flow

GitHub-flow

# Git-flow

Удачная модель ветвления для Git

Пожалуйста, перестаньте рекомендовать Git Flow

# Trunk-Based Development

Trunk-Based Development

# Статьи по теме

  1. Как сделать мир (или хотя бы ваш проект) чуточку лучше
  2. Как следует писать комментарии к коммитам