When Does CI/CD Actually Trigger? Git Branches, PRs & Merges Explained (Part 3/3)
In Part 1, we built a strong mental model of CI/CD and understood why software teams rely on automation to avoid chaos.
In Part 2, we explored what actually happens after git push—from builds and automated tests to quality checks and deployment preparation.
But there is still one question that confuses almost every developer at some point:
When does CI/CD actually start?
If you create a branch, should CI run?
If you commit locally, does the pipeline trigger?
Does automation only begin after a Pull Request?
Or only after merging?
These are important questions because understanding when CI runs is just as important as understanding what CI does.
By the end of this article, you’ll clearly understand:
Why branch creation alone does nothing
When CI/CD actually gets triggered
The difference between local and remote branches
How professional Git workflows operate
Why CI may run multiple times for the same feature
What developers should do before pushing code
Let’s begin with one of the biggest misconceptions beginners have.
The Biggest Beginner Misconception
A common misunderstanding looks something like this:
“I created a branch. Why didn’t CI run?”
This question makes complete sense when you're first learning Git workflows.
You might think:
git checkout -b feature/login
means:
“A new branch exists, so CI should start checking things.”
But nothing happens.
Why?
Because CI/CD systems usually don’t care about what happens only on your laptop.
This is the key idea:
CI reacts to events in the remote repository, not your local machine.
Creating a branch locally is simply a change in your personal working environment.
No one else can see it.
The remote repository has no idea that branch exists yet.
Which means:
No trigger = no pipeline.
To understand this better, we first need to understand the difference between local and remote branches.
Local Branches vs Remote Branches
When learning Git, many developers mentally treat branches as one thing.
In reality, there are two worlds:
Local branches
Remote branches
Understanding this distinction instantly clears up most CI confusion.
Local Branches
When you run:
git checkout -b feature/login
or:
git switch -c feature/login
you create a branch only on your computer.
At this point:
The branch exists locally
You can write code
You can commit changes
You can experiment freely
But:
The remote repository still knows nothing about it.
No automation runs because nothing has changed remotely.
You can think of local development like drafting notes privately.
Until you share them:
Nobody sees anything.
Remote Branches
Things change when you run:
git push origin feature/login
Now the branch becomes visible remotely.
The repository receives:
New code
New commits
A new branch reference
At this point:
CI finally has something to react to.
The remote repository sees an event and says:
“Something changed. Time to validate.”
That event may trigger:
Builds
Tests
Security scans
Quality checks
Deployment preparation
This is why many developers suddenly see:
Checking pipeline status...
right after pushing.
So, What Actually Triggers CI/CD?
At its core:
CI/CD is event-driven automation.
An event happens.
Automation wakes up.
No event?
Nothing happens.
The most common triggers look like this.
1. Push Events
The most common trigger is simply pushing code.
Example:
git push origin feature/login
The moment code reaches the remote repository, the CI system notices the change and starts running checks.
Typically, teams configure pipelines to run:
On every branch push
On important branches only
On specific naming patterns
For example:
feature/*
develop
main
release/*
Why run CI on pushes?
Because early feedback matters.
Imagine you accidentally introduced:
A syntax error
A broken dependency
A failing test
Invalid configuration
Instead of waiting until code review or deployment, CI catches the problem immediately.
That short feedback loop saves enormous time.
2. Pull Request Events
Another extremely common trigger is opening a Pull Request.
Example:
feature/login → develop
The moment the PR opens, CI runs again.
At first this may feel repetitive.
You may wonder:
“Didn’t CI already run when I pushed?”
Yes.
But now the system is asking a different question:
Is this code safe to merge into a shared branch?
This matters because shared branches affect everyone.
The pipeline may validate:
Build success
Test results
Code quality checks
Security scans
Merge conflicts
Many organizations enforce a simple rule:
No green CI = no merge.
You may have seen messages like:
❌ Checks failed
or:
✅ All checks passed
That status determines whether reviewers are even allowed to merge code.
3. Merge Events
Interestingly, CI often runs again after merging.
This confuses many developers.
The logic becomes clearer once you think about collaboration.
Imagine:
Developer A changes authentication.
Developer B changes database behavior.
Individually, both Pull Requests passed CI successfully.
However, software systems are interconnected.
Once merged together, unexpected interactions may occur.
Perhaps:
Authentication now expects an old schema
Database responses changed
Edge cases appear
The merged system behaves differently from isolated feature branches.
That is why teams rerun pipelines after merges.
The question changes from:
“Does this feature work?”
to:
“Does the combined system still work?”
4. Scheduled Pipelines
Not every trigger comes from developers.
Many teams configure scheduled automation.
For example:
Every night at 2 AM
The system may automatically run:
Full regression suites
Security scans
Dependency health checks
Performance tests
Why schedule them?
Because some validations are expensive and slow.
Running them on every commit would waste time and infrastructure.
Instead, teams treat scheduled jobs like health checkups.
The software is periodically inspected to ensure everything remains healthy.
5. Manual Triggers
Sometimes engineers intentionally run pipelines manually.
Example scenarios:
Testing infrastructure
Re-running failed jobs
Verifying release candidates
Debugging flaky builds
A developer might click:
Run Pipeline
or:
Re-run Failed Jobs
This gives teams flexibility when automation alone isn’t enough.
A Real Developer Workflow (What Actually Happens)
Now that we understand triggers, let’s zoom out and see what a normal workflow looks like.
Imagine a developer is building a login feature.
The flow often looks like this:
main
↓
develop
↓
feature/login
↓
Write code locally
↓
Commit changes
↓
Push branch
↓
CI runs
↓
Open Pull Request
↓
CI runs again
↓
Code review
↓
Merge
↓
CI runs on merged result
This explains why pipelines often seem to run multiple times.
They are validating different stages of software safety.
Why CI Runs Multiple Times
At first glance, repeated CI checks can feel wasteful.
But every run serves a different purpose.
| Stage | Goal |
|---|---|
| Push | Catch problems early |
| Pull Request | Validate merge readiness |
| Merge | Validate integrated result |
| Schedule | System-wide health checks |
Think of it like airport security.
You may pass multiple checkpoints before boarding.
Each checkpoint validates something different.
CI works similarly.
The more critical the software system, the more validation gates exist.
What Developers Should Do Before Pushing Code
One of the biggest beginner mistakes is assuming:
“CI will catch everything.”
That mindset causes problems.
Good developers try to catch issues before CI does.
A healthy workflow usually looks like this.
1. Pull Latest Changes
Before starting work:
git pull origin develop
This reduces merge conflicts and ensures you're building on updated code.
2. Create a Proper Feature Branch
Avoid working directly on:
main
Instead:
git checkout -b feature/login
Keep work isolated.
3. Commit Small Logical Changes
Bad commit:
updated stuff
Better commit:
feat: add login validation
Smaller commits make debugging easier and reviews cleaner.
4. Review Your Own Changes
Before pushing:
git diff
Ask yourself:
Did I leave debug logs?
Is unused code still present?
Did I accidentally commit secrets?
Does this logic actually make sense?
Self-review prevents embarrassing mistakes.
5. Run Checks Locally
Before pushing:
Run tests.
Run linters.
Build locally.
Why?
Because waiting 10 minutes for CI to fail over something obvious wastes everyone's time.
The goal is:
Make CI confirm quality—not discover basic mistakes.
Common Beginner Mistakes
Here are some mistakes almost everyone makes early on.
Working Directly on main
Risky and hard to recover from.
Always isolate work.
Giant Commits
Huge commits make debugging painful.
Smaller logical commits improve traceability.
Ignoring Failed CI
A failed pipeline is not “someone else’s problem.”
It means:
Something is wrong.
Treat CI feedback seriously.
Assuming git push Means Production
This is one of the biggest misconceptions.
A push usually starts validation.
Production comes much later.
The Final Mental Model
If you remember only one thing from this entire series, remember this:
CI/CD is event-driven automation.
Creating a branch alone does nothing.
Committing locally does nothing.
CI begins when meaningful events happen remotely:
Pushes
Pull Requests
Merges
Scheduled jobs
Manual triggers
Once triggered, automation validates whether your software is safe to move forward.
That’s the core idea behind modern software delivery.
Wrapping Up the Series
Across this series, we answered three major questions:
Part 1 — What is CI/CD?
We understood why CI/CD exists, how Integration Hell shaped modern development, and why software teams trust automation.
Part 2 — What Happens After git push?
We explored the journey of code through builds, testing, quality checks, artifacts, staging, and deployment preparation.
Part 3 — When Does CI/CD Trigger?
We learned how Git workflows, branches, Pull Requests, and merges interact with automation in real engineering teams.
If you’ve followed all three parts, you now have a much stronger mental model of CI/CD than most beginners—and probably clearer than many working developers who only interact with pipelines without fully understanding them.
Happy building 🚀