Использование хуков git и предварительной фиксации для улучшения качества репо
Я видел, как это происходило в самых разных компаниях. От Fortune 500 до небольших стартапов кажется, что все упускают первый шаг, необходимый для того, чтобы ваша кодовая база не испортилась плохими и неработающими коммитами. Это крючки для фиксации git.
Что такое хуки Git?
Перехватчики Git позволяют запускать пользовательский код при различных событиях git. Типичным вариантом использования для этого будет запуск вашего линтера до того, как вы позволите выполнить фиксацию. Вы можете просмотреть несколько примеров хуков в своем репо, перейдя на .git/hooks/
и просмотрите все те, которые заканчиваются на «.sample».
Есть 2 категории крючков. Локальный и серверный. Мы просто коснемся локальных ловушек, так как я считаю их наиболее нереализованной ценностью.
Ниже у меня есть скриншот того, как выглядит pre-commit.sample
. Если вы похожи на меня (не являетесь поклонником сценариев оболочки), то приведенный ниже код выглядит довольно устрашающе ... Так что мы не будем его использовать!
Есть 3 причины, по которым мы не собираемся использовать встроенные сценарии оболочки для наших хуков. Во-первых, их нельзя вернуть в систему контроля версий. Существует обходной путь, позволяющий проверять хуки git, но он включает в себя изменение вашего глобального core.hooksPath
, что не является устойчивым. Большинство репозиториев не согласятся с тем, где должны быть хуки, поэтому лучше не изменять путь ваших хуков постоянно.
Вторая причина заключается в том, что большинство людей не хотят изучать сценарии оболочки. Вы уже владеете достаточно сложными языками. Сценарии оболочки нечасто подходят людям.
Наконец, и это главное. Вы не можете делиться или распространять хуки. Вам буквально нужно будет копировать хуки из одного проекта в другой. Это много дублирования кода. Это превратило бы хуки обновления для всех ваших репозиториев в кошмар. Вот где на помощь приходит предварительная фиксация.
Предварительная фиксация - надежное решение
Pre-Commit - это библиотека, позволяющая нам использовать и распространять хуки git. Хотя он написан на Python, он может вызывать любую исполняемую программу, что означает, что вы можете настроить все свои хуки из одного места.
Использовать предварительную фиксацию очень просто:
python -m pip install pre-commit pre-commit install
Затем вам просто нужно создать .pre-commit-hooks.yaml
файл в корне вашего репозитория. Этот файл хуков описывает предварительную фиксацию, где он может найти крючки фиксации, которые необходимо запустить. Ниже приведен пример того, как это выглядит.
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v2.3.0
hooks:
- id: check-yaml
- id: end-of-file-fixer
- id: trailing-whitespace
- repo: https://github.com/Yelp/detect-secrets
rev: v1.1.0
hooks:
- id: detect-secrets
args: ["scan"]
- repo: https://github.com/dtaivpp/commit-msg-regex-hook
rev: v0.1.0
hooks:
- id: commit-msg-hook
args: ["--pattern='[A-Z]{3,4}-[0-9]{3,6} \\| [\\w\\s]*'"
stages: [commit-msg]
Вот как это работает; при первом запуске предварительная фиксация загружает репозитории хуков в их собственные виртуальные среды с помеченной версией. Затем он будет запускать их для файлов, которые были изменены и проверяются. Если вы обновите «rev», чтобы повысить версию, при следующем запуске он загрузит новую версию для проверки вашего кода.
Первое репо в конфигурации проверит YAML, чтобы убедиться, что он правильно отформатирован. Затем он исправит конец файла и удалит все ненужные конечные пробелы. Это всего лишь шаги по чистоте кода.
Затем будет запущено обнаружение секретов Yelp, которое проверит, что вы не проверяете какие-либо ключи или секреты своего репо. Он знаком со многими различными типами токенов и даже может обнаруживать пароли, ища строки с высокой энтропией. Очень важно найти секреты до того, как они будут введены в коммит, так как после того, как они будут зафиксированы, будет сложно очистить историю git.
Наконец, commit-msg-regex-hook
проверит и подтвердит, что указанное мной сообщение фиксации соответствует предоставленному шаблону регулярного выражения. Особенно горжусь этим шагом, когда создавал этот плагин.
Примечание: чтобы запустить этот, вам нужно запустить pre-commit install --hook-type commit-msg
. Этот перехватчик является перехватчиком сообщения фиксации и устанавливается в другой файл перехватчика, нежели обычные перехватчики перед фиксацией.
Предварительная фиксация - расширенное использование
Также можно добавить любое количество плагинов. Если у него есть исполняемый файл, предварительная фиксация может его использовать.
Крючки для пуховки
Обычный вариант использования предварительной фиксации - это автоматическая линковка ваших файлов. Для python вы можете использовать приведенный ниже код для автоматического запуска pylint
и отказа от его фиксации, если ваш линтер оценивает ваш код ниже 8. Он выдаст результат линтинга и сообщит вам области, которые необходимо улучшить, чтобы получить более высокий балл.
- repo: git://github.com/pycqa/pylint rev: pylint-2.6.0 hooks: - id: pylint args: ["--fail-under=8"]
Проверка типа / проверка конфигурации
Если вы используете какой-либо инструмент, который в значительной степени полагается на файлы конфигурации, такие как Kubernetes, CircleCI, Ansible и т. Д., Вы, вероятно, испытали разочарование, проверяя свой код только для того, чтобы он потерпел неудачу, потому что вы не ввели имя переменной или ваш отступ был отключен.
Здесь может помочь предварительная фиксация. Многие из этих инструментов предоставляют утилиты для проверки этих типов файлов. Например, с CircleCI вы можете использовать команду circleci config validate
. Это можно добавить в качестве ловушки перед фиксацией, чтобы перед каждой фиксацией вы могли знать, что ваши файлы конфигурации действительны. Ниже приведена ловушка перед фиксацией, которая может помочь проверить файлы CircleCI. Благодарим KoBoldMetals за эту фиксацию.
- repo: https://github.com/KoBoldMetals/pre-commit-circleci rev: v0.0.4 hooks: - id: circleci-validate
Таким образом, вы готовы улучшить опыт разработчиков, и ваша компания поблагодарит вас за то, что ваше репо теперь будет иметь лучшую безопасность, меньше неудачных фиксаций и в целом более качественный код.