[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-git-chto-takoe-git-hooks":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":17,"progress":18,"seo":19},1338,"chto-takoe-git-hooks",44,"git","Git","📦","Что такое git hooks?","Git hooks — это скрипты, которые автоматически запускаются при определённых событиях Git (коммит, пуш, merge и т.д.) и позволяют автоматизировать проверки и обеспечивать соблюдение правил разработки.\n\n### Client-side хуки (на стороне разработчика)\n\nХранятся в `.git\u002Fhooks\u002F` каждого репозитория.\n\n| Хук | Когда срабатывает | Типичное использование |\n|---|---|---|\n| `pre-commit` | Перед созданием коммита | Линтинг, форматирование, проверка секретов |\n| `prepare-commit-msg` | После создания сообщения по умолчанию | Автоматическое добавление номера задачи |\n| `commit-msg` | После ввода commit message | Валидация формата сообщения (Conventional Commits) |\n| `pre-push` | Перед отправкой на сервер | Запуск тестов, проверка качества кода |\n| `post-commit` | После успешного коммита | Уведомления |\n| `post-merge` | После merge | Установка зависимостей |\n\n### Server-side хуки (на стороне сервера)\n\n| Хук | Когда срабатывает | Типичное использование |\n|---|---|---|\n| `pre-receive` | При получении push | Проверка прав, валидация коммитов |\n| `update` | При обновлении каждой ветки | Проверка политик для конкретной ветки |\n| `post-receive` | После получения push | Деплой, уведомления, CI-триггеры |\n\n### Примеры\n\n\u003Cdetails>\n\u003Csummary>pre-commit: проверка стиля кода\u003C\u002Fsummary>\n\n```bash\n#!\u002Fbin\u002Fbash\n# .git\u002Fhooks\u002Fpre-commit\n\n# Запустить checkstyle перед коммитом\ncd examples && mvn checkstyle:check\nif [ $? -ne 0 ]; then\n    echo \"Checkstyle failed. Fix issues before committing.\"\n    exit 1\nfi\n```\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>commit-msg: валидация формата\u003C\u002Fsummary>\n\n```bash\n#!\u002Fbin\u002Fbash\n# .git\u002Fhooks\u002Fcommit-msg\n\nCOMMIT_MSG_FILE=$1\nCOMMIT_MSG=$(cat \"$COMMIT_MSG_FILE\")\n\n# Проверка Conventional Commits формата\nPATTERN=\"^(feat|fix|docs|style|refactor|test|chore)(\\(.+\\))?: .{1,72}\"\nif ! echo \"$COMMIT_MSG\" | grep -qE \"$PATTERN\"; then\n    echo \"Commit message must follow Conventional Commits format:\"\n    echo \"   type(scope): description\"\n    echo \"   Examples: feat(auth): add JWT validation\"\n    echo \"             fix: correct null pointer in UserService\"\n    exit 1\nfi\n```\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>pre-push: запуск тестов\u003C\u002Fsummary>\n\n```bash\n#!\u002Fbin\u002Fbash\n# .git\u002Fhooks\u002Fpre-push\n\necho \"Running tests before push...\"\ncd examples && mvn test\nif [ $? -ne 0 ]; then\n    echo \"Tests failed. Push aborted.\"\n    exit 1\nfi\n```\n\n\u003C\u002Fdetails>\n\n### Установка хуков\n\n```bash\n# Хуки находятся в .git\u002Fhooks\u002F\n# Сделать хук исполняемым\nchmod +x .git\u002Fhooks\u002Fpre-commit\n\n# Для шаринга хуков в команде — хранить в директории проекта\nmkdir -p .githooks\n# и настроить Git:\ngit config core.hooksPath .githooks\n```\n\n### Ключевые моменты\n\n- Хуки из `.git\u002Fhooks\u002F` не коммитятся — они локальны для каждого клона\n- Для шаринга хуков используйте отдельную директорию (`.githooks\u002F`) и `git config core.hooksPath`\n- Хук должен вернуть exit code 0 для успеха и ненулевой для блокировки операции\n- Client-side хуки можно обойти через `--no-verify` — server-side хуки обойти нельзя\n\n### Частые ошибки\n\n- Забывать делать хуки исполняемыми (`chmod +x`)\n- Создавать слишком медленные pre-commit хуки — раздражает разработчиков\n- Полагаться только на client-side хуки для критичных проверок — их можно обойти\n- Хранить хуки только в `.git\u002Fhooks\u002F` — они теряются при клонировании\n\n### Как используется в 2026\n\n- Инструменты Husky (JS), pre-commit (Python) и lefthook (Go) автоматизируют установку и управление хуками\n- Хуки используются для Conventional Commits validation, автоформатирования, проверки секретов\n- Server-side хуки заменяются CI\u002FCD pipelines и branch protection rules в GitHub\u002FGitLab\n- Хуки интегрированы в pipelines: при неуспехе pre-commit в CI блокируется merge PR\n\n> **На собеседовании:** разделите хуки на client-side (pre-commit, commit-msg, pre-push) и server-side (pre-receive, post-receive). Ключевое: client-side можно обойти через `--no-verify`, server-side — нельзя. Покажите знание инструментов: Husky, lefthook, pre-commit. Частый вопрос: как шарить хуки в команде — ответ: `.githooks\u002F` + `core.hooksPath`.","","junior",[7,15,16],"основы","commands",[],null,{"title":20,"description":21,"ogTitle":22,"ogDescription":23,"keywords":24,"schemaAnswer":33,"featuredSnippetReady":34},"Что такое git stash — Gymterview","git stash: временное сохранение незакоммиченных изменений. Операции push\u002Fpop\u002Fapply\u002Fdrop, флаг -u для untracked, создание ветки из stash, типичные сценарии.","Git stash: временное сохранение изменений — Gymterview","Как использовать git stash: push, pop vs apply, флаг -u, создание ветки. Типичный сценарий — срочное переключение контекста.",[25,26,27,28,29,30,31,8,32],"git stash","stash pop","stash apply","stash push","временное сохранение","untracked","LIFO","собеседование","git stash — команда для временного сохранения незакоммиченных изменений в стековом хранилище (LIFO). pop = apply + drop (применяет и удаляет), apply — оставляет в списке. Флаг -u включает untracked-файлы. Stash привязан к репозиторию, не к ветке. git stash push --staged (Git 2.35+) сохраняет только проиндексированные. Можно создать ветку из stash: git stash branch \u003Cname>.",true]