Essential Concepts of Git Hooks for Automation Quiz

Explore key aspects of Git Hooks and their use in automating workflows within the git tools ecosystem. Assess your understanding of hook types, configuration, and common automation scenarios to improve your source control practices.

1. Types of Git Hooks

   Which type of Git hook is triggered before changes are committed to the repository, allowing you to run checks or scripts automatically?

   1. pre-commit
   2. post-push
   3. pre-merge
   4. commit-prep

   Explanation: The 'pre-commit' hook runs before a commit is finalized, enabling automated checks or formatting actions to maintain code quality. 'Post-push' does not exist as a standard hook in git, making it an incorrect choice. 'Pre-merge' is also not a recognized Git hook, and 'commit-prep' is not an actual Git hook name. Only 'pre-commit' fits the scenario described.

2. Hook Script Configuration

   When setting up a custom Git hook, what is the most important requirement for the script file in the hooks directory to execute properly?

   1. The script must have executable permissions.
   2. The script must be written in Python.
   3. The script must be named with a .git extension.
   4. The script must be added to the remote repository.

   Explanation: For Git to run a hook script, it must have executable permissions; otherwise, it will be ignored. While hooks can be in various programming languages, not just Python, making option B incorrect. The script does not require a .git extension (option C). Git hooks are local and not shared via the repository, so option D is also incorrect.

3. Automated Actions Example

   If you want to automatically run tests each time code is pushed to a remote repository, which Git hook should you use?

   1. pre-push
   2. post-commit
   3. prepare-rebase
   4. pre-checkout

   Explanation: The 'pre-push' hook is ideal for running tests or checks before code is sent to a remote repository, helping catch issues before sharing changes. 'Post-commit' only runs after commits are made and doesn't pertain to pushing code. 'Prepare-rebase' is used during rebasing workflows, and 'pre-checkout' is not a standard hook for this scenario. Thus, only 'pre-push' is correct.

4. Default Hook Files

   Upon initializing a new Git repository, what will you typically find in the .git/hooks directory?

   1. Sample scripts for various hook types with .sample extensions
   2. A blank directory requiring manual hook creation
   3. Executable binaries for common hooks
   4. Hooks that are automatically activated by default

   Explanation: New git repositories include sample hook scripts with a '.sample' extension to guide users. The directory is not empty, so option B is incorrect. There are no executable binaries placed there by default (option C), and none of the hooks are activated until explicitly created and made executable (option D). The presence of samples helps users understand possible hooks.

5. Sharing Hook Logic

   What is a common approach to ensure a team uses the same set of Git hook logic across all contributors, given that hooks are not included in version control by default?

   1. Store hook scripts externally and use setup instructions or automation to install them locally
   2. Rely on the default hooks shipped with every git client
   3. Add the .git/hooks directory directly to version control
   4. Email scripts individually to every team member

   Explanation: Since the .git/hooks directory is not tracked by version control, teams often manage hooks in a separate directory within the project and share setup scripts or automation steps to install them. Default hooks are only samples and are not sufficient (option B). Tracking .git/hooks in version control (option C) is not supported by git, and emailing scripts individually (option D) is inefficient and prone to error. External storage with installation instructions is best practice.