Почему не любишь Git Hooks?

Почему я отношусь к Git Hooks с осторожностью

Прежде чем говорить о "нелюбви", важно подчеркнуть: Git Hooks — это мощный и полезный механизм. Они позволяют автоматизировать рутинные задачи, обеспечить единые стандарты кода и повысить качество проекта. Однако в долгосрочной перспективе и в командной разработке их нативная реализация имеет ряд фундаментальных недостатков, которые заставляют меня относиться к их прямому использованию с большой осторожностью.

Основные проблемы нативных Git Hooks

1. Отсутствие версионного контроля и сложность распространения

    Скрипты хуков хранятся в локальной директории `.git/hooks/` и **не коммитятся** в репозиторий. Это главный недостаток. Чтобы "раздать" их команде, приходится использовать дополнительные инструменты (скрипты-установщики, мануальные инструкции), что ненадежно и ведет к рассинхронизации.

```bash
# .git/hooks/pre-commit - лежит ВНЕ репозитория
# Его нельзя закоммитить и расшарить командой
ls -la .git/hooks/
# pre-commit.sample
# pre-push.sample
# ... и т.д.
```

2. "Молчаливое" игнорирование при сбоях

    Если хук завершился с ненулевым кодом ответа, Git прерывает операцию. Однако если самого файла хука **не существует**, Git просто молча продолжает работу. Это приводит к ложному чувству безопасности: разработчик думает, что все проверки пройдены, хотя хуки у него просто не установлены.

1. Сложность управления зависимостями и окружением

    Хуки — это исполняемые скрипты (Bash, Python, Node.js). Для их работы на машине каждого разработчика должно быть настроено необходимое окружение с правильными версиями интерпретаторов и библиотек. Это создает огромные накладные расходы на поддержку и является источником "работает у меня" проблем.

```bash
#!/bin/bash
# Пример: pre-commit хук, требующий конкретной версии Node и пакетов
node --version | grep "v18" || { echo "Требуется Node.js 18"; exit 1; }
npm run lint || exit 1 # А если 'npm' нет? Или скрипта 'lint' нет?
```

4. Отсутствие гибкой конфигурации и обхода

    Бывают ситуации, когда проверку нужно временно обойти (например, для коммита WIP или исправления критического бага в проде). С нативными хуками это делается только через флаг `--no-verify`, который отключает **все** хуки для данной операции, что не всегда безопасно. Нет возможности точечного отключения или условной логики.

Альтернативный подход: использование менеджеров хуков

Именно из-за этих проблем я предпочитаю вместо нативных хуков использовать специализированные инструменты — менеджеры Git Hooks. Наиболее зрелый и популярный из них для JavaScript/TypeScript проектов — Husky.

Почему Husky (или аналог) решает указанные проблемы:

• Версионность: Конфигурация хуков (pre-commit, commit-msg, pre-push) хранится в package.json или отдельном файле .husky/, которые коммитятся в репозиторий.
• Автоматическая установка: После клонирования репозитория и запуска npm install хуки автоматически устанавливаются в локальную директорию .git/hooks/ благодаря послеустановочным скриптам Husky.
• Управление зависимостями: Хуки могут быть тесно интегрированы в скрипты npm, которые выполняются в контролируемом проектном окружении (с его node_modules). Это гарантирует согласованность.
• Гибкость: Легко настраивать, какие именно проверки запускать на каком этапе. Можно создавать сложные пайплайны.

Пример современной конфигурации с Husky и lint-staged:

// package.json
{
  "scripts": {
    "prepare": "husky install",
    "lint": "eslint . --ext .ts,.tsx",
    "format": "prettier --write ."
  },
  "devDependencies": {
    "husky": "^9.0.0",
    "lint-staged": "^15.0.0",
    "eslint": "^8.0.0",
    "prettier": "^3.0.0"
  },
  "lint-staged": {
    "*.{js,ts,tsx}": ["eslint --fix", "prettier --write"]
  }
}

# .husky/pre-commit - этот файл УЖЕ в репозитории
#!/usr/bin/env sh
. "$(dirname "$0")/_/husky.sh"

# Запускаем проверку только для файлов в индексе
npx lint-staged

Заключение

Я не "не люблю" Git Hooks как концепцию. Напротив, я считаю их необходимым элементом профессиональной разработки для автоматизации линтинга, форматирования, тестирования и проверки сообщений коммитов. Однако я критически отношусь к их нативному, "голому" использованию в командных проектах.

Мой подход — всегда использовать менеджер хуков (Husky для JS/TS, pre-commit для Python, Lefthook для кросс-платформенных проектов). Это превращает Git Hooks из хрупкого рудимента в надежный, версионируемый и управляемый инструмент, который действительно повышает качество кодовой базы и культуры разработки, а не создает скрытые проблемы и разочарования.