Git as the Foundation

Pipelines react to Git events

Every CI/CD system is, underneath the marketing, an event listener for Git. A push, a tag, a pull request — these are the triggers that fire workflows. If you understand Git well, you understand half of CI/CD already.

The events that matter on GitHub:

push — to any branch, or filtered to specific branches.
pull_request — opened, synchronized (new commit pushed), reopened, ready_for_review.
tag push — usually for release pipelines (push a v1.2.3 tag → trigger release workflow).
schedule — cron-like, for nightly builds and dependency scans.
workflow_dispatch — manual trigger from the UI or API.
repository_dispatch — external system pings the repo.

Branching strategies and CI shape

Two common branching strategies have very different CI implications:

Trunk-based — short-lived feature branches, merged daily. CI runs on every PR and every push to main. Smooth, fast, requires discipline.
Git Flow — long-lived develop, release, hotfix branches. CI is more complex (different gates per branch class). Slower, more ceremony, useful for slow release cadences (regulated industries, packaged software).

Pick the strategy first; the CI structure follows.

Code

Different triggers per workflow·yaml

# .github/workflows/pr.yml — runs on PRs only
name: pr-checks
on:
  pull_request:
    types: [opened, synchronize, reopened]

# .github/workflows/release.yml — runs on tag pushes
name: release
on:
  push:
    tags: ['v*.*.*']

# .github/workflows/nightly.yml — runs at 06:00 UTC daily
name: nightly
on:
  schedule:
    - cron: '0 6 * * *'
  workflow_dispatch: {}

Pipelines react to Git events

Branching strategies and CI shape

Code

External links

Exercise

Progress

Comments 0