DevOps Classroom notes 07/Sep/2025

Git Hooks

• Hooks are scripts that automatically execute at a certain point in repositories workflow
  • before commmit
  • after push
• hooks are present in .git/hooks directory
• Types of Git hooks
  • Client side hooks: Run on your local machine (local repo)
  • Server side hooks: Run on the remote repository
• Client Side hooks: Commmonly used
  • pre-commit: Runs before a commit is finalized (good for code linting)
  • commit-msg: Runs after entering a commit message (enforce message style)
  • pre-push: Runs before pushing to remote (check tests, run security scans)
• Server side hooks:
  • pre-recieve: Runs before the changes are accepted by remote repo
  • update: runs on each branch being updated
  • post-recieve: Runs after changes are accepted
• A hook can be written in any language (shell/python…) the file needs to be executable
• Refer Here for repo with hooks
• To enable some of the hooks, cloud hosted git remote repos started giving web hooks
• Client Side hooks

Hook Name	When It Runs	Purpose / Usage
pre-commit	Before git commit runs (after staging, before editor opens).	Used to check code style, run linters/tests, block commits with issues.
prepare-commit-msg	Before the commit message editor is shown.	Modify or generate default commit messages (e.g., include ticket IDs).
commit-msg	After commit message is entered, before finalizing commit.	Validate commit message format (e.g., enforce conventional commits).
post-commit	After a commit is created.	Notifications/logging (e.g., send a message, update a dashboard).
pre-rebase	Before rebasing begins.	Used to prevent rebasing certain branches or enforce rules.
post-rewrite	After commands that replace commits (e.g., git rebase, git commit --amend).	Useful for adjusting external systems or notifications.
post-checkout	After git checkout changes branches or restores files.	Set up environment, regenerate files, or update configs.
post-merge	After a successful git merge.	Restore permissions, run tests, or notify about conflicts resolved.
pre-push	During git push, after remote refs are checked.	Run tests/lint before pushing, prevent pushes to protected branches.
pre-applypatch	Before applying a patch with git am.	Validate or modify the patch before it’s applied.
applypatch-msg	During git am, right after patch is applied but before commit is created.	Edit or validate the commit message from the patch.
post-applypatch	After git am has applied the patch.	Notify or perform cleanup tasks.

• Server side Hooks.

Hook Name	When It Runs	Purpose / Usage
pre-receive	When a push is received, before any refs are updated.	Enforce rules like branch protection, code review requirements, reject commits that don’t meet standards.
update	After pre-receive, runs once per branch (ref) being updated.	More granular control than pre-receive, e.g., allow/reject pushes to specific branches.
post-receive	After refs are updated successfully.	Trigger CI/CD pipelines, deploy code, send notifications, or update issue trackers.
post-update	After post-receive, once for each branch updated.	Useful for tasks like updating exported repos or triggering hooks for consumers.
push-to-checkout	When a push updates the current branch that is checked out (bare repos don’t use this).	Automatically build/deploy working copy after push (common in simple git-based deployments).

Github Worklfows

• A Github workflow is written in yaml file with any name and exists in .github folder
• Refer Here for official docs on workflow syntax
• Github workflow will have following toplevel elements
  • name: A friendly name of the workflow (optional)
  • on: Defines events that trigger the workflow
  • env: Environmental variables available to all jobs (optional)
  • defaults: Default settings (optional)
  • permissions: Sets default Github token permission for all jobs (optional)
  • jobs: Defines the set of jobs to run

Lets focus on required top level keys

on: Defines when the workflow should run

jobs: Defines what has to run

• A workflow can be triggered by events and they have three categories
  • Webhook trigger/git events:
    • Events that trigger github workflow
  • Scheduled Triggers
  • Manual Triggers:
    • workflow_dispatch
    • repository_dispatch: this starts all the workflows in the repository.
• Hint: On Visual studio code install Github Actions extension
  

Lets create a new repo and configure a simple workflow

Gets triggered when changes are pushed to branch develop.

• Create a new repo
• inside this repo create a .github/workflows folder
• now add a main.yml file

---
name: "hello to main branch"
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: "Hello to main branch"
        run: echo "Hello to main branch"

Gets triggered on creating a pr into branch main

• Refer Here for changes