Паттерны git commit

Мы, разработчики, часто пользуемся Git. Мы используем его и в личных проектах, и в командных, и в опенсорсе. Учитывая это, важно правильно применять git commit. Наличие последовательного и стандартизированного языка помогает всем участникам проекта понимать произошедшие изменения.

Эта иллюстрация показывает, насколько вредным может быть плохо прокомментированный коммит. Совершенно невозможно понять, что поменялось и в каком контексте. В долгосрочной перспективе эффект еще более пагубный, поскольку страдает поддерживаемость программного обеспечения.

Учитывая это, давайте немного поговорим о паттерне Conventional Commits.

Что такое Conventional Commits?

Conventional Commits — это простое соглашение о коммитах. Оно содержит ряд правил, соблюдение которых помогает иметь явную и хорошо структурированную историю коммитов в проектах.

Как использовать соглашение о сообщениях коммитов?

Правила очень просты. Как показано ниже, у нас есть тип, контекст (область действия) и сообщение (тема) коммита.

!type(?scope): !subject
<?body>
<?footer>

Восклицательный знак указывает на обязательные атрибуты, а вопросительный — на необязательные.

subject: сообщение коммита

Мы сообщаем нашей команде, что сделает коммит, если его применить. В английском языке нужно использовать повелительное наклонение, а не прошедшее время.

Проверка правильности построения предложения — подставить в начало условие и вспомогательный глагол will.

Паттерн: «If applied, this commit will…».

Аналог на русском: «При применении этот коммит <что сделает?>».

Сообщение «If applied, this commit will change the markup» имеет гораздо больше смысла, чем «If applied, this commit will changed the markup».

type: типы коммитов

Тип должен сообщить нам, какое изменение или итерация производится. Исходя из правил соглашения, мы имеем следующие типы:

test: указывает на любое создание или изменение кода тестов. Пример — создание модульных тестов.
feat: указывает на разработку новой функции для проекта. Примеры: добавление сервиса, функциональности, конечной точки и т.д.
refactor: используется, когда происходит рефакторинг кода, не влияющий на логику/правила системы. Пример — изменения после ревью кода.
style: используется при изменениях форматирования и стиля кода, которые никак не меняют систему. Примеры: смена руководства по стилю или соглашения о линтинге, исправление отступов, удаление пробелов, удаление комментариев и т.д….
fix: используется при исправлении ошибок, которые порождают баги в системе. Пример — применение обработки для функции, которая ведет себя не так, как ожидалось, и возвращает ошибку.
chore: указывает на изменения в проекте, которые не влияют на систему или тестовые файлы. Это изменения, связанные с разработкой. Примеры: изменение правил для eslint, добавление prettier, добавление расширений файлов в .gitignore.
docs: используется при изменениях в документации проекта. Пример: добавление сведений в документацию API, измение README и т.д.
build: используется для указания изменений, которые влияют на процесс сборки проекта, или внешних зависимостей. Примеры: Gulp, добавление/удаление зависимостей npm и т.д..
perf: указывает на изменение, которое улучшает производительность системы. Пример — замена ForEach на While.
ci: используется для указания на изменения в конфигурационных файлах CI. Примеры: Circle, Travis, BrowserStack и т.д.
revert: указывает на отмену предыдущего коммита.

Примечания:

Для каждого коммита указывается только один тип.
type — обязательный атрибут.
Если вы не знаете, какой тип использовать, вероятно, это большое изменение, и можно разделить этот коммит на два или на большее число коммитов.
Разница между build и chore может быть довольно тонкой, что может привести к путанице. Поэтому важно знать, какой тип когда использовать. В случае с Node.js, например, мы можем считать, что когда происходит добавление/изменение определенной зависимости разработки, присутствующей в devDependencies, мы используем chore. Для изменений/добавлений общих зависимостей проекта, которые оказывают прямое и реальное влияние на систему, мы используем build.

scope: контекст коммита

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

Несмотря на то, что атрибут scope не является обязательным, его можно использовать для добавления контекста. Это позволит сделать сообщение коммита максимально кратким и лаконичным. Помните, что область действия нужно указывать в скобках. Разделяются скоупы символом /.

Заключение

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

Перевод статьи «Git Commit Patterns».

От редакции Techrocks. Если вам интересна тема сообщений коммитов, можем предложить еще пару статей:

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]