# 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:

```bash
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:

1.  Local branches
    
2.  Remote branches
    

Understanding this distinction instantly clears up most CI confusion.

## Local Branches

When you run:

```bash
git checkout -b feature/login
```

or:

```bash
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:

```bash
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:

```text
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:

```bash
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:

```text
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:

```text
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:

```text
❌ Checks failed
```

or:

```text
✅ 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:

```text
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:

```text
Run Pipeline
```

or:

```text
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:

```text
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:

```bash
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:

```text
main
```

Instead:

```bash
git checkout -b feature/login
```

Keep work isolated.

* * *

## 3\. Commit Small Logical Changes

Bad commit:

```text
updated stuff
```

Better commit:

```text
feat: add login validation
```

Smaller commits make debugging easier and reviews cleaner.

* * *

## 4\. Review Your Own Changes

Before pushing:

```bash
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 🚀