Practise vocabulary for pre-commit configuration, hook stages, CI enforcement, and bypass communication.
0 / 5 completed
1 / 5
A pre-commit hook is best described as:
Pre-commit hooks are local git hooks (.git/hooks/pre-commit) that run checks before the commit is finalised. The pre-commit framework manages these hooks declaratively via .pre-commit-config.yaml — consistent across all developer machines.
2 / 5
The phrase 'the pre-commit hook runs `black` and `isort` before each commit to enforce code style' means:
Pre-commit hooks with Black/isort enforce consistent code formatting: they run the formatters and either auto-fix the files (then fail the commit so the developer stages the changes) or block the commit until the developer runs the formatters manually.
3 / 5
The command 'git commit --no-verify' is used to:
--no-verify bypasses ALL hooks. It's a last resort: broken hooks blocking urgent work, or deliberately committing incomplete code with a WIP note. Overuse undermines the value of hooks. Teams sometimes audit --no-verify usage in CI by checking commit logs.
4 / 5
Running pre-commit checks in CI (in addition to locally) is described as ensuring:
Local hooks + CI hooks is defense-in-depth: local hooks give fast feedback at commit time; CI enforcement catches anything that slipped through (--no-verify, hooks not installed, hooks misconfigured). Without CI, local hooks are purely advisory.
5 / 5
In a .pre-commit-config.yaml, the 'stages' key for a hook specifies:
Pre-commit supports multiple stages: commit (default), prepare-commit-msg, commit-msg, post-commit, push, post-merge. Expensive checks (unit tests) can be staged to push rather than commit — fast feedback locally, thorough checks before sharing.