Complete Git → CI/CD Development Flow

The complete development flow is:

Developer
    ↓
Create Branch
    ↓
Make Code Changes
    ↓
Commit
    ↓
Push
    ↓
Pull Request
    ↓
Code Review + PR Validation
    ↓
Merge into main
    ↓
CI Build
    ↓
Create Artifact
    ↓
Deployment
    ↓
Environment

Let's take a practical example where a developer needs to implement a login feature.

1. Developer

A developer receives a requirement such as:

Implement the user login functionality.

First, the developer gets the latest source code.

git switch main
git pull origin main

Now the local main is up to date.

Remote main
A──B──C
      ↓
git pull
      ↓
Local main
A──B──C

2. Create a Branch

The developer should normally avoid developing directly on main.

Create a feature branch:

git switch -c feature/login

Older commonly used syntax:

git checkout -b feature/login

Now:

main
A──B──C
       \
        feature/login

The developer works independently without affecting main.

Why use a branch?

It provides isolation.

Multiple developers can work simultaneously:

                 feature/login
                /
A──B──C────────
       \
        feature/payment
         \
          feature/profile

3. Make Changes and Commit

The developer modifies the application.

Check the changes:

git status

Stage them:

git add .

Commit them:

git commit -m "Add login functionality"

Now Git history might look like:

main
A──B──C
       \
        D
        ↑
   feature/login

D is the new commit.

Important

A commit is initially stored in the developer's local Git repository.

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

At this stage, GitHub or Azure Repos does not normally have commit D.

4. Push

The developer pushes the branch to the remote repository.

git push -u origin feature/login

Here:

• origin = remote repository
• feature/login = branch
• -u = establishes the upstream/tracking relationship

Before push:

Local

A──B──C──D
         ↑
  feature/login


Remote

A──B──C

After push:

Local                 Remote

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

The feature branch now exists on GitHub or Azure Repos.

5. Create a Pull Request

The developer creates a Pull Request (PR).

For example:

Source:
feature/login

Target:
main

Effectively, the developer is requesting:

"Please review the changes in feature/login and merge them into main."

feature/login
      │
      │ Pull Request
      ▼
     main

A Pull Request does not itself mean the code has been merged.

It creates a review and validation workflow around the proposed changes.

6. PR Validation / CI Checks

In many real projects, CI runs before the merge, not only afterward.

For example:

Pull Request
     ↓
PR Validation Pipeline
     ↓
Restore
     ↓
Build
     ↓
Unit Tests
     ↓
Static Analysis / Other Checks
     ↓
Pass / Fail

For an ASP.NET Core project, the pipeline might execute:

dotnet restore
dotnet build
dotnet test

If the pipeline fails:

PR
 ↓
Build Failed ✗
 ↓
Developer fixes code
 ↓
Commit
 ↓
Push
 ↓
PR updated
 ↓
CI runs again

This prevents broken code from being merged into main.

7. Code Review

Other developers or technical leads review the Pull Request.

They may check:

• Code correctness
• Coding standards
• Architecture
• Security
• Performance
• Tests
• Error handling
• Maintainability

For example, a reviewer may add a comment:

LoginService.cs

"Please move this database logic
to the repository layer."

The developer makes the requested change:

git add .
git commit -m "Address PR review comments"
git push

Because the branch already has an upstream branch, simply:

git push

is normally enough.

The existing Pull Request automatically includes the new commit.

PR
 │
 ├── Commit D
 │
 └── Commit E ← Review fix

There is normally no need to create another PR.

8. Branch Protection / Policies

Organizations usually protect important branches such as main.

GitHub

Branch protection/rulesets can require things such as:

main
 │
 ├── Pull Request required
 ├── Required approvals
 ├── Required status checks
 └── Conversations resolved

Azure Repos

Branch policies can require things such as:

main
 │
 ├── Minimum reviewers
 ├── Build validation
 ├── Required reviewers
 ├── Comment resolution
 └── Work-item linking

Therefore, a developer cannot simply bypass the expected workflow where permissions and policies enforce it.

9. Merge

Once:

Review approved       ✓
Build passed          ✓
Tests passed          ✓
Policies satisfied    ✓

the Pull Request can be merged.

Before:

A──B──C──────────── main
       \
        D──E────── feature/login

After the merge, conceptually:

A──B──C────────────F── main
       \          /
        D────────E

The exact history depends on the merge strategy:

• Merge commit
• Squash merge
• Rebase merge

Now the login functionality is part of main.

10. CI Build After Merge

A push/change on main can trigger another CI pipeline.

PR Merge
   ↓
main updated
   ↓
CI Trigger
   ↓
Pipeline starts

The pipeline may execute:

Checkout
    ↓
Restore Dependencies
    ↓
Build
    ↓
Unit Tests
    ↓
Quality/Security Checks
    ↓
Publish
    ↓
Artifact

For ASP.NET Core:

dotnet restore
dotnet build --configuration Release
dotnet test --configuration Release
dotnet publish --configuration Release

11. Build Artifact

A successful CI pipeline commonly creates a deployable output called an artifact.

For example:

Source Code
    ↓
CI Build
    ↓
Artifact

Depending on the application, an artifact could be:

• Published ASP.NET Core application
• ZIP package
• Docker image
• NuGet package
• Compiled Angular application

An important principle is:

Build once and promote the same artifact through environments when practical.

For example:

Build
  ↓
Artifact v1.5.0
  │
  ├──→ Dev
  ├──→ SIT
  ├──→ UAT
  └──→ Production

This avoids rebuilding different binaries for each environment.

12. Deployment

Deployment is generally considered the CD part of the CI/CD process.

CI
│
├── Restore
├── Build
├── Test
└── Publish Artifact

          ↓

CD
│
├── Deploy Dev
├── Deploy SIT
├── Deploy UAT
└── Deploy Production

The exact stages depend on the organization.

For example:

Artifact
   ↓
DEV
   ↓
SIT
   ↓
UAT
   ↓
Production

Some stages may be automatic, while sensitive environments may require approvals.

For example:

Build Successful
      ↓
Deploy DEV
      ↓
Deploy SIT
      ↓
Deploy UAT
      ↓
Manual Approval
      ↓
Production

13. Complete End-to-End Flow

Putting everything together:

Requirement / Work Item
          ↓
      Developer
          ↓
Update local main
          ↓
Create feature branch
          ↓
    feature/login
          ↓
    Modify Code
          ↓
       git add
          ↓
      git commit
          ↓
       git push
          ↓
GitHub / Azure Repos
          ↓
   Create Pull Request
          ↓
   PR Validation CI
          ↓
      Build + Test
          ↓
      Code Review
          ↓
Fix comments if required
          ↓
      Approval
          ↓
Branch Rules / Policies satisfied
          ↓
   Merge into main
          ↓
   main updated
          ↓
    CI Pipeline
          ↓
 Restore → Build → Test
          ↓
  Publish Artifact
          ↓
    CD Pipeline
          ↓
 DEV → SIT → UAT
          ↓
      Approval
          ↓
     Production

14. GitHub and Azure DevOps Mapping

The same workflow can use different products.

They can also be mixed:

GitHub Repository
       ↓
Pull Request
       ↓
Azure Pipelines
       ↓
Build + Test
       ↓
Deployment

15. Key Points

• Developers normally work on feature branches, not directly on main.
• git commit saves changes to the local repository.
• git push sends commits to the remote repository.
• A Pull Request proposes merging one branch into another.
• Code review happens through the Pull Request.
• CI should commonly validate the PR before merge.
• Branch protection/policies can require approvals and successful CI checks.
• After approval, the feature branch is merged into main.
• Updating main can trigger another CI build.
• CI typically performs:

Checkout → Restore → Build → Test → Publish

• The build can produce an artifact.
• CD takes that artifact and deploys it to environments.
• Production deployment may require manual approval.
• CI and deployment are related but different: CI validates/builds the code; CD delivers the resulting artifact to environments.

16. Interview Answer

In a typical development workflow, I first update main and create a feature branch such as feature/login. I make the required changes, stage them, commit them locally, and push the feature branch to the remote repository. Then I create a Pull Request from the feature branch to main. The PR normally goes through automated CI validation and code review. If reviewers request changes, I update the same branch, commit, and push again, which updates the existing PR. Once the required approvals and CI checks pass, the PR is merged into main. The merge can trigger the main CI pipeline, which restores dependencies, builds the application, runs tests, and produces a deployable artifact. The CD process then promotes that artifact through environments such as Dev, SIT, UAT, and finally Production, with approvals where required.