Git Commit / Pull Request Triggering a CI Pipeline

1. What is it?

A CI (Continuous Integration) pipeline is an automated process that typically builds and tests the application whenever developers make relevant code changes.

A Git commit by itself is normally only a local operation:

git commit -m "Add login feature"

That does not normally trigger a remote CI pipeline until the commit reaches the remote repository, usually through:

git push origin feature/login

Similarly, creating or updating a Pull Request (PR) can trigger a CI pipeline to validate the proposed changes before they are merged.

In simple terms:

Code Change
    ↓
Commit
    ↓
Push
    ↓
GitHub / Azure Repos
    ↓
Configured CI Trigger
    ↓
CI Pipeline
    ↓
Build + Test + Validation

2. Simple Syntax / Sample

Git commands

git switch -c feature/login

# Make code changes

git add .
git commit -m "Add login feature"

git push -u origin feature/login

The important distinction is:

git commit
    ↓
Commit exists locally
    ↓
Usually NO remote CI pipeline

git push
    ↓
Commit reaches remote repository
    ↓
CI trigger detects the event
    ↓
Pipeline starts

3. GitHub Actions Example

A GitHub Actions workflow can be configured like this:

name: CI

on:
  push:
    branches:
      - main

  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: dotnet build

      - name: Test
        run: dotnet test

Here there are two important triggers:

on:
  push:

and:

pull_request:

So GitHub can start the workflow when configured push or PR events occur.

4. Azure Pipelines Example

An Azure Pipeline can use a YAML configuration such as:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: ubuntu-latest

steps:
  - script: dotnet build
    displayName: Build

  - script: dotnet test
    displayName: Test

Here:

trigger:

defines the branches whose pushes should automatically trigger the pipeline.

For PR validation in Azure Repos, teams commonly configure Build Validation as a branch policy on a protected branch such as main.

5. Detailed Explanation

Suppose a developer is working on:

feature/login

They make changes and commit them:

git add .
git commit -m "Implement login"

At this point:

Developer Machine

feature/login

A──B──C
      ↑
   new commit

The remote repository may still contain:

Remote Repository

feature/login

A──B

The CI system does not normally know about commit C yet.

Step 1 — Developer pushes

git push origin feature/login

Now:

Local                 Remote

A──B──C    ──────→    A──B──C

The remote platform receives the push event.

Step 2 — CI system evaluates the trigger

For example, the pipeline might be configured to run for:

Push to main

or:

Pull Request targeting main

The CI system checks whether the event matches its configured trigger.

Push / PR Event
      ↓
Does it match CI trigger?
      ↓
     Yes
      ↓
Start Pipeline

If it does not match:

Push / PR Event
      ↓
Does it match CI trigger?
      ↓
      No
      ↓
No pipeline run

Step 3 — Pipeline obtains the source code

When the pipeline starts, an agent/runner gets the relevant source code.

For example:

GitHub / Azure Repos
        ↓
CI Runner / Agent
        ↓
Checkout Source

Step 4 — Dependencies are restored

For an ASP.NET Core application:

dotnet restore

For Angular:

npm ci

Step 5 — Application is built

ASP.NET Core:

dotnet build --configuration Release

Angular:

npm run build

Step 6 — Automated tests run

For example:

dotnet test

The pipeline could contain:

Checkout
    ↓
Restore
    ↓
Build
    ↓
Unit Tests
    ↓
Other Checks
    ↓
CI Result

Step 7 — CI reports success or failure

If everything succeeds:

CI Pipeline
    ↓
Build ✓
Tests ✓
Checks ✓
    ↓
SUCCESS

If a test fails:

CI Pipeline
    ↓
Build ✓
Tests ✗
    ↓
FAILED

The result can then be displayed on the Pull Request.

6. Pull Request Validation Flow

Suppose the developer pushes:

feature/login

and creates:

feature/login → main

A typical workflow is:

Developer
    ↓
Commit
    ↓
Push feature/login
    ↓
Create Pull Request
    ↓
PR CI Pipeline
    ↓
Restore
    ↓
Build
    ↓
Tests
    ↓
┌───────────────┐
│ Pipeline Pass?│
└───────┬───────┘
        │
   ┌────┴────┐
   │         │
  Yes        No
   │         │
   ↓         ↓
PR can     Fix code
proceed      ↓
   │       Push again
   ↓         ↓
Review     CI runs again
   ↓
Merge
   ↓
main

If the branch is protected, a successful CI check can be made a requirement for merging.

7. Push Trigger vs Pull Request Trigger

A common setup uses both:

feature/login
     ↓
Pull Request
     ↓
PR Validation CI
     ↓
Build + Test
     ↓
Review + Approval
     ↓
Merge into main
     ↓
Push/change on main
     ↓
Main CI Pipeline

The main pipeline may then produce artifacts or feed a later CD/deployment process.

8. Important Distinction: Commit vs Push

This is particularly important in interviews.

git commit

git commit -m "Fix login bug"

Creates the commit in your local Git repository.

Working Directory
      ↓
git add
      ↓
Staging Area
      ↓
git commit
      ↓
Local Repository

It generally does not notify GitHub or Azure Repos.

git push

git push origin feature/login

Transfers your commits to the remote repository.

Local Repository
       ↓
    git push
       ↓
GitHub / Azure Repos
       ↓
Repository Event
       ↓
CI Trigger
       ↓
Pipeline

Therefore, saying:

"Every git commit automatically triggers CI"

is usually inaccurate.

A better statement is:

When the commit is pushed to the remote repository, the resulting repository event can trigger CI if the pipeline is configured for that event.

9. Key Points

• CI stands for Continuous Integration.
• A local git commit normally does not trigger a remote CI pipeline.
• git push sends commits to GitHub or Azure Repos.
• The remote platform generates repository events.
• Pipeline configuration determines which events start CI.
• CI can be triggered by pushes, Pull Requests, and other configured events.
• GitHub commonly uses GitHub Actions for CI.
• Azure DevOps commonly uses Azure Pipelines.
• PR validation typically performs:

Checkout → Restore → Build → Test → Validation

• A protected main branch can require the CI pipeline to succeed before allowing a PR to merge.
• After additional commits are pushed to the PR branch, CI can run again to validate the updated code.

10. Interview Answer

A local Git commit normally does not directly trigger a remote CI pipeline. When the developer pushes the commit to GitHub or Azure Repos, the remote repository generates an event. If the CI configuration is set to respond to that branch or event, the pipeline starts automatically. Similarly, creating or updating a Pull Request can trigger a PR validation pipeline. The pipeline typically checks out the code, restores dependencies, builds the application, runs automated tests, and reports the result. Branch protection rules or Azure Repos branch policies can then require that CI validation succeeds before the Pull Request is merged into main.