Я видел, как люди пишут всевозможные треп в сообщениях коммитов Git, и был счастлив, наконец, найти хорошо структурированную историю коммитов, как на следующем изображении, и сразу же сосредоточился на ее изучении.
После небольшого исследования я обнаружил, что вышеупомянутый стиль используется в Руководстве по сообщениям фиксации Angular. С тех пор я слежу за ним во всех своих проектах. Этот стиль ясен, лаконичен и согласован, что позволяет легко отслеживать и поддерживать любую кодовую базу.
Несмотря на то, что эти рекомендации упоминаются в руководстве по разработке Angular, их можно увидеть и во многих других проектах (особенно в тех, где участвует Google).
Итак, давайте разберемся с этим.
Формат сообщения фиксации
Каждое сообщение фиксации состоит из заголовка, тела и необязательного нижнего колонтитула. . Заголовок имеет специальный формат, который включает тип, область и тему:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>Типы сообщений фиксации:
- сборка: изменения, влияющие на систему сборки или внешние зависимости (например, области действия: gulp, broccoli, npm).
- ci: изменения файлов конфигурации и скриптов CI (примеры областей: Travis, Circle, BrowserStack, SauceLabs)
- docs: изменения только в документации
- feat: новая функция
- fix: исправление ошибки.
- perf: изменение кода, повышающее производительность.
- рефакторинг: изменение кода, которое не устраняет ошибку и не добавляет функции.
- стиль: изменения, не влияющие на смысл кода (пробелы, форматирование, отсутствие точек с запятой и т. д.).
- test: добавление отсутствующих тестов или исправление существующих тестов.
Сфера
Кандидаты в объем зависят от проекта и используемых технологий. Выбор области применения остается на усмотрение разработчика. (Angular использует свой специфический набор областей видимости.)
Тема
Тема содержит краткое описание изменения:
- используйте повелительное наклонение в настоящем времени: «изменить», а не «изменить» или «изменить»
- не пишите первую букву с большой буквы
- без точки / точки (.) в конце
Нижний колонтитул (необязательно)
Нижний колонтитул используется для цитирования проблем, которые закрывает эта фиксация (если таковые имеются).
Примеры
docs(server): add javadoc comments on methods
- Это сообщение подразумевает, что изменения, внесенные в этот коммит, касаются только изменений документации (или тому подобного) в коде на стороне сервера.
feat(core): add new command 'Upload' to UI
- Добавление новой функции - в основной функционал приложения.
fix: update GET headers (#142)
- Исправьте ошибки, относящиеся к заголовкам HTTP GET, которые закрывают проблему 142.
Почему это важно?
В этом руководстве эффективно говорится о том, что если ваша фиксация не может быть описана в соответствии с этим руководством, тогда созданные вами коммиты не структурированы наилучшим образом, то есть вы не должны фиксировать код без его доработки, или изменения должны быть разделены на несколько коммитов.
Это больше, чем просто следование набору правил. Сообщения фиксации, написанные в этом формате, позволяют создавать журнал изменений проекта (как это сделано в Angular) и использовать его в других инструментах Git.
Я пришел к выводу, что следование этим рекомендациям или их собственной версии - полезно, так же как соглашения о кодировании помогают поддерживать порядок в программировании.
Попробуйте Commitizen -cli, инструмент, который можно интегрировать в ваши проекты, чтобы ускорить процесс написания содержательных сообщений о коммитах.
(Примечание: этот пост был вдохновлен Руководством по участию в Angular: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit)
