commit-msg hook for message validation in Git - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of a commit-msg hook script

Given this commit-msg hook script, what will be the output if the commit message is "Fix bug in login"?

Git

#!/bin/sh
MESSAGE_FILE=$1
MESSAGE=$(cat "$MESSAGE_FILE")
if echo "$MESSAGE" | grep -qE '^\[JIRA-[0-9]+\]'; then
  exit 0
else
  echo "Error: Commit message must start with a JIRA ticket ID like [JIRA-123]"
  exit 1
fi

A Error: Commit message is too short

B No output, commit succeeds

C Syntax error in script

D Error: Commit message must start with a JIRA ticket ID like [JIRA-123]

💡 Hint

Check if the commit message starts with the required pattern.

The script checks if the commit message starts with a pattern like [JIRA-123]. Since "Fix bug in login" does not start with that, it prints the error and exits with failure.

🧠 Conceptual

intermediate

Purpose of commit-msg hook

What is the main purpose of a commit-msg hook in Git?

A To check and validate the commit message before allowing the commit

B To automatically push commits to remote repositories

C To merge branches after commit

D To delete untracked files before commit

💡 Hint

Think about what happens right after you write a commit message.

The commit-msg hook runs after you write a commit message and before the commit is finalized. It is used to validate or modify the commit message.

❓ Troubleshoot

advanced

Why does the commit-msg hook not run?

You created a commit-msg hook script in .git/hooks/ but it does not run when committing. What is the most likely reason?

A The repository is not initialized

B The script file is not executable

C The hook script is named commit-msg.txt

D The commit message is empty

💡 Hint

Check file permissions for scripts in .git/hooks/

Git only runs hook scripts that have executable permissions. If the script is not executable, Git ignores it.

🔀 Workflow

advanced

Implementing commit-msg hook for multiple rules

You want a commit-msg hook that enforces these rules:
1. Commit message must start with [PROJ-123]
2. Commit message must be at least 15 characters long
Which script correctly implements both checks?

A

#!/bin/sh
MSG=$(cat "$1")
if ! echo "$MSG" | grep -qE '^\[PROJ-[0-9]+\]'; then
  echo "Error: Message must start with [PROJ-123]"
  exit 1
fi
if [ ${#MSG} -lt 15 ]; then
  echo "Error: Message must be at least 15 characters"
  exit 1
fi
exit 0

B

#!/bin/sh
MSG=$(cat "$1")
if echo "$MSG" | grep -qE '^\[PROJ-[0-9]+\]' || [ ${#MSG} -ge 15 ]; then
  exit 0
else
  echo "Error: Commit message invalid"
  exit 1
fi

C

#!/bin/sh
MSG=$(cat "$1")
if echo "$MSG" | grep -qE '^\[PROJ-[0-9]+\]' && [ ${#MSG} -ge 15 ]; then
  exit 1
else
  echo "Error: Commit message invalid"
  exit 0
fi

D

#!/bin/sh
MSG=$(cat "$1")
if ! echo "$MSG" | grep -qE '^\[PROJ-[0-9]+\]' || [ ${#MSG} -lt 15 ]; then
  echo "Error: Commit message invalid"
  exit 1
fi
exit 0

💡 Hint

Both conditions must be true to pass validation.

Option A checks each condition separately and exits with error if either fails. Other options have logic errors or inverted exit codes.

✅ Best Practice

expert

Best practice for sharing commit-msg hooks in a team

What is the best way to ensure all team members use the same commit-msg hook for message validation?

A Add the hook script to .gitignore so it is not tracked

B Ask each member to manually create the hook in their .git/hooks/ folder

C Store the hook script in the repository and use a setup script to copy it to .git/hooks/

D Use a global Git hook configured on each developer's machine

💡 Hint

Think about version controlling the hook and automating installation.

Git does not version control .git/hooks/, so storing hooks in the repo and copying them during setup ensures consistency. Global hooks are possible but less flexible for project-specific rules.

Practice

1. What is the main purpose of a commit-msg hook in Git?

easy

A. To check and validate the commit message before the commit is saved

B. To automatically push commits to the remote repository

C. To merge branches after a commit

D. To delete old commits from history

Solution

1. Step 1: Understand the role of Git hooks

   Git hooks are scripts that run at specific points in Git's workflow to automate tasks or checks.

2. Step 2: Identify the function of the commit-msg hook

   The commit-msg hook runs after a commit message is entered but before the commit is finalized, allowing validation of the message.

3. Final Answer:

   To check and validate the commit message before the commit is saved -> Option A

4. Quick Check:

   commit-msg hook = validate commit message [OK]

Hint: commit-msg hook validates commit messages before saving [OK]

Common Mistakes:

• Confusing commit-msg hook with pre-push or post-commit hooks
• Thinking it automatically pushes commits
• Assuming it modifies commit history

2. Which of the following is the correct way to make a commit-msg hook executable on a Unix-like system?

easy

A. chmod 000 .git/hooks/commit-msg

B. chmod +x .git/hooks/commit-msg

C. git commit --hook commit-msg

D. git hook enable commit-msg

Solution

1. Step 1: Understand file permissions for hooks

   Git hooks are scripts stored in the .git/hooks directory and must be executable to run.

2. Step 2: Identify the correct command to make a file executable

   The command chmod +x adds execute permission to the file, enabling the hook to run.

3. Final Answer:

   chmod +x .git/hooks/commit-msg -> Option B

4. Quick Check:

   chmod +x = make executable [OK]

Hint: Use chmod +x to enable hook execution [OK]

Common Mistakes:

• Using chmod 000 which removes all permissions
• Trying git commands that don't exist for hooks
• Not setting executable permission, so hook won't run

3. Given this commit-msg hook script snippet, what will happen if the commit message is empty?

#!/bin/sh
if [ -z "$1" ]; then
  echo "Error: Commit message is empty." >&2
  exit 1
fi

medium

A. The commit will be blocked with an error message

B. The commit message will be replaced with a default message

C. The commit will proceed without any message

D. The script will ignore the message and exit with 0

Solution

1. Step 1: Analyze the script condition

   The script checks if the first argument $1 is empty using [ -z "$1" ]. In the commit-msg hook, $1 is the path to a temporary file containing the proposed commit message.

2. Step 2: Understand Git's behavior

   Since $1 is the file path, it is never empty, so the condition [ -z "$1" ] is false. However, the script as written incorrectly checks the variable $1 instead of the content of the file. To check if the commit message is empty, the script should check the content of the file, e.g., if [ ! -s "$1" ] or if [ -z "$(cat $1)" ]. As is, the script will not block empty commit messages.

3. Final Answer:

   The commit will proceed without any message -> Option C

4. Quick Check:

   $1 is file path, not content; checking it for emptiness is incorrect [OK]

Hint: $1 is file path, not content; check with `cat $1` [OK]

Common Mistakes:

• Thinking exit 1 allows commit to proceed
• Assuming the message is replaced automatically
• Confusing $1 with the commit message text instead of file path

4. You wrote this commit-msg hook to reject messages shorter than 10 characters:

#!/bin/sh
MSG=$(cat "$1")
if [ ${#MSG} -lt 10 ]; then
  echo "Commit message too short." >&2
  exit 1
fi

But it does not block short messages. What is the likely problem?

medium

A. The hook script is not executable

B. The commit message file path is incorrect

C. The shell does not support ${#MSG} syntax for string length

D. The script should use -z instead of -lt

Solution

1. Step 1: Check the script logic

   The script correctly reads the commit message and checks its length using ${#MSG} which is valid in sh/bash.

2. Step 2: Consider common hook issues

   If the hook is not executable, Git will ignore it and allow commits without running the script.

3. Final Answer:

   The hook script is not executable -> Option A

4. Quick Check:

   Non-executable hook = script not run [OK]

Hint: Make sure hook script is executable with chmod +x [OK]

Common Mistakes:

• Assuming ${#MSG} is invalid in shell
• Confusing file path with message content
• Using wrong test operators like -z for length comparison

5. You want to enforce commit messages to start with a ticket number like PROJ-123: followed by a space and description. Which commit-msg hook snippet correctly validates this pattern?

hard

A. #!/bin/sh
MSG=$(cat "$1")
if echo "$MSG" | grep -qE '^PROJ-[a-z]+: .+'; then
echo "Invalid ticket format" >&2
exit 1
fi

B. #!/bin/sh
MSG=$(cat "$1")
if echo "$MSG" | grep -q '^PROJ-[0-9]+: .+'; then
exit 1
fi

C. #!/bin/sh
if [ -z "$1" ]; then
echo "Empty message" >&2
exit 0
fi

D. #!/bin/sh
MSG=$(cat "$1")
if ! echo "$MSG" | grep -qE '^PROJ-[0-9]+: .+'; then
echo "Commit message must start with 'PROJ-<number>: '" >&2
exit 1
fi

Solution

1. Step 1: Understand the required pattern

   The commit message must start with 'PROJ-' followed by digits, a colon, a space, then some text.

2. Step 2: Analyze each option's regex and logic

   #!/bin/sh MSG=$(cat "$1") if ! echo "$MSG" | grep -qE '^PROJ-[0-9]+: .+'; then echo "Commit message must start with 'PROJ-<number>: '" >&2 exit 1 fi uses grep -qE with '^PROJ-[0-9]+: .+' and exits with error if pattern not matched, which is correct. #!/bin/sh MSG=$(cat "$1") if echo "$MSG" | grep -q '^PROJ-[0-9]+: .+'; then exit 1 fi exits on match (wrong logic). #!/bin/sh if [ -z "$1" ]; then echo "Empty message" >&2 exit 0 fi exits 0 on empty message (wrong). #!/bin/sh MSG=$(cat "$1") if echo "$MSG" | grep -qE '^PROJ-[a-z]+: .+'; then echo "Invalid ticket format" >&2 exit 1 fi checks for lowercase letters after PROJ- which is incorrect.

3. Final Answer:

   #!/bin/sh MSG=$(cat "$1") if ! echo "$MSG" | grep -qE '^PROJ-[0-9]+: .+'; then echo "Commit message must start with 'PROJ-<number>: '" >&2 exit 1 fi -> Option D

4. Quick Check:

   grep -qE '^PROJ-[0-9]+: .+' = valid pattern check [OK]

Hint: Use grep -qE with ^PROJ-[0-9]+: .+ to validate pattern [OK]

Common Mistakes:

• Reversing logic: exiting on match instead of no match
• Using wrong regex for digits or colon
• Exiting with 0 on error conditions