Basic Git Concepts: A DevOps Engineer’s

Strong Foundation

What is Git?

Why Do We Use It in DevOps?

Imagine you're building a massive skyscraper with a team of architects and engineers.

Every small change matters — you can't afford chaos. Git acts like a time machine and a
collaboration manager for your project’s source code.

Git is a distributed version control system (VCS) that allows developers to track changes,
collaborate effectively, and revert mistakes if necessary.

In DevOps, speed and stability are non-negotiable. Git helps teams work in parallel, experiment
safely, and merge code seamlessly — forming the backbone of modern Continuous Integration and
Continuous Deployment (CI/CD) pipelines.

Without Git, coordinating software development would feel like juggling with re — one wrong
move, and you risk burning down months of work!

Git vs GitHub: Understanding the Difference

A common confusion for beginners: Git and GitHub are not the same thing.

• Git is the tool you use locally. It's the engine that tracks changes to your les.

• GitHub is the service where you can host your Git repositories online.

Think of Git as your personal diary where you write daily notes, and GitHub as a library where
you can publish your diary so others can collaborate, review, or contribute.

In DevOps, using a remote hosting service like GitHub, GitLab, Bitbucket, or Azure Repos is
crucial because it enables centralized collaboration, backup, code reviews, and triggering
automated pipelines based on Git events.
fi
fi
 Install Git and Basic Con guration
Setting up Git is like moving into a new house — a little setup makes everything smoother later.

1. Install Git:
◦ Windows: Download from git-scm.com and install.

◦ Mac/Linux: Usually installed by default or use package managers (brew

install git or sudo apt install git).

2. Basic con guration (only once per machine):

git config --global user.name "Your Name"

git config --global user.email "[email protected]"

These commands personalize your commits with your identity — so your team knows who made
what changes.

You can also con gure other settings like default editors or merge tools later.

Git Life Cycle: The Journey of Your Code

Understanding Git's internal process is like knowing the production chain in a factory:

• Working Directory: Where you create or edit your les.

• Staging Area (Index): A place where you prepare speci c changes before making them
of cial.

• Repository (Commit History): Where your nalized snapshots are stored permanently.

The typical ow:

• You make changes ➔ stage changes ➔ commit them ➔ push to remote (like GitHub).

This clear separation prevents mistakes — you can pick and choose what to commit, and avoid
accidentally sending un nished work!
fi
fi
fl
fi
fi
fi
fi
fi
fi
 How to Initialize a Git Repository
Every journey begins with a single step — in Git, it’s:

git init

This simple command creates a hidden .git folder in your project directory, which holds all the
magic — the entire version control system.

From this moment, Git starts watching every move you make.

Check the Status of Files

Before making any decision, you need a snapshot of the current situation:

git status

This command shows:

• Which les are modi ed

• Which are staged for the next commit

• Which les are untracked (new les Git doesn’t know about yet)

It’s your real-time health report of your project!

Adding Changes to Staging Area

To move changes from the Working Directory to the Staging Area:

git add <file> # Adds a specific file

git add . # Adds all changes in the current directory

Think of git add as selecting clothes before packing — you’re deciding what should be
included in your next travel bag (commit).
fi
fi
fi
fi
Committing Changes with a Message
Once you're happy with what you've staged, you can record a permanent snapshot with:

git commit -m "A meaningful message"

The message is crucial — it’s the story behind that change. A good commit message is clear,
concise, and describes what and why, not just how.

E.g.,

"Fix bug in user authentication logic"

"Add payment gateway integration"

Checking Commit History

Want to go back in time? Git gives you a history book of all actions:

git log

(Shows full details: commits, author, timestamp, messages)

Or if you want a quick summarized view:

git log --oneline

(Each commit is shown in one simple line — great for quick glances.)

Viewing Differences Between Versions

Before committing, you might want to see exactly what changed:

• View unstaged changes:

git diff
• View staged changes (already added but not yet committed):

git diff --staged

This helps avoid embarrassing mistakes like committing half-done work.

 Undo Changes (Restore & Reset)
Mistakes happen — Git understands and offers two lifesaving commands:

• Restore a le to its last committed state (cancel uncommitted edits):

git restore <file>

• Unstage a le you accidentally added (but keep your edits):

git reset HEAD <file>

Think of restore as "I don't want these edits at all",

and reset HEAD as "Oops! I added the wrong le; let me just remove it from packing
without losing it."
fi
fi
fi
 Intermediate Git Concepts – Taking Control of
Collaboration & Code Flow

Cloning a Repository – git clone <repo_url>

Imagine you’re joining a new DevOps project. The code is already on GitHub or GitLab.

Your rst task? Bring a copy to your system:

git clone https://github.com/example/project.git

This command downloads the entire repository, including all les, branches, and history, into
your local system.

It's like photocopying an entire book so you can read and contribute to it without touching the
original.

From now on, your local copy is connected to the remote one — so you can pull updates or push
your changes.

Remote Repositories – Connecting Local and Cloud

A remote is simply a link to a repository hosted somewhere like GitHub or Bitbucket.

Add a Remote Repository

If you initialized a project locally and later decide to push it to GitHub, connect it with:

git remote add origin https://github.com/user/repo.git

• origin is the default name for the remote.

• You can verify with git remote -v to see all connected remotes.

Now you’ve “linked your project to the cloud”.

fi
fi
Push, Pull, and Fetch: Talking to Remotes
Push (Send your commits to remote)

git push origin main

You’re saying: “Hey GitHub, here’s my work – add it to the main branch!”

You’ll use this every time you want to upload your local changes.

Pull (Get latest changes from remote and merge)

git pull origin main

You're saying: “Bring in updates from the remote main branch and merge them into mine.”

Great for keeping in sync with teammates — but it merges right away.

Fetch (Just download changes, don’t merge yet)

git fetch origin

This silently grabs the latest changes from remote — but doesn’t touch your current les.

Use it when you want to check what's new before deciding to merge.

Branching – Work in Isolation Without Breaking the Main

Line
Think of branches as sandboxes — isolated copies of your code where you can experiment freely.

Create a Branch

git branch feature-xyz

This creates a new branch off your current commit.

Switch Between Branches

git checkout feature-xyz

This moves you to that branch — like changing oors in a building.

fl
fi
Create and Switch at Once

git checkout -b feature-xyz

Shortcut for: “Create this branch and take me there.”

Now you’re ready to code without worrying about breaking the main project.

Merging – Bringing Ideas Back Together

Once your branch is ready, you need to merge it back to the main branch (or any other branch):

git checkout main

git merge feature-xyz

This pulls in the changes from feature-xyz into main.

Behind the scenes, Git compares changes between both branches and tries to automatically
combine them.

Visualizing the Branch Graph

To see a beautiful tree of your branches and commits:

git log --oneline --graph —all

This gives a visual of how branches split and merged — super helpful for debugging or team
discussions.

Resolving Merge Con icts

Sometimes, Git can’t auto-merge changes. For example, two developers edited the same line of
code differently.

You’ll get a con ict.

Git will mark the le like this:

<<<<<<< HEAD
your change
=======
someone else's change
>>>>>>> feature-xyz
fl
fi
fl
You need to edit the le manually, decide which change (or both) to keep, and then:

git add <file>

git commit

In DevOps, this is common during hot xes, release merges, or CI/CD pipeline deployments with
multiple contributors.

Stay calm, read the code, communicate with your team.

Deleting Branches
Once a branch has done its job, clean up to avoid clutter:

Delete Local Branch

git branch -d feature-xyz

Use -d to delete only if it’s merged. Use -D to force-delete even if unmerged.

Delete Remote Branch

git push origin --delete feature-xyz

This tells the remote (e.g., GitHub): “Remove this branch from your side too.”

This cleanup is crucial in professional work ows to keep repositories organized and CI/CD
pipelines manageable.
fi
fi
fl
 Important GIT Commands

git stash – “Temporarily save your work-in-progress without committing it.”

Syntax:

git stash

Example:

You’re working on a hot x, but suddenly need to switch branches to address a critical issue. Just
stash your current changes, switch, and come back later.

git stash pop – “Apply your last stashed changes back to your working
directory.”

Syntax:

git stash pop

Example:

After xing the production bug, you return to your original task. Use git stash pop to
recover where you left off — like pulling saved edits from a drawer.

git rebase – “Reapply commits from your branch onto another base commit,
rewriting history.”

Syntax:

git rebase <branch>

Example:

You want your feature branch to have a clean, linear history on top of main, so you rebase it to
make the commit tree look like a straight timeline.
fi
fi
 git cherry-pick – “Selectively apply a speci c commit from another
branch.”

Syntax:

git cherry-pick <commit_hash>

Example:

You xed a critical bug on a test branch and want that x in main without merging the entire
branch — cherry-pick that golden commit like picking a single cherry from a tree.

git tag – “Mark speci c points in history, like version releases.”

Syntax:

git tag v1.0.0

Example:

Before deploying to production, tag the release commit as v1.0.0 — making it easier to track
and rollback if needed.

git clean – “Remove untracked les and directories from your working
directory.”

Syntax:

git clean -fd

Example:

After testing scripts or temporary builds, use git clean -fd to sweep away all untracked les
— like cleaning your desk before the next task.

git revert – “Create a new commit that undoes the effect of a previous
commit (safe undo).”

Syntax:

git revert <commit_hash>

fi
fi
fi
fi
fi
fi
Example:

You committed a con g that breaks staging. Use revert to undo it without changing history,
keeping the team’s timeline intact.

git reset --hard – “Dangerously reset your repo and wipe out
uncommitted changes — use with caution!”

Syntax:

git reset --hard <commit_hash>

Example:

You went down a wrong path and want to completely reset to a clean state — reset --hard is
like pressing “nuclear undo” (but be sure you really want it).

git pull – “Fetch and merge remote changes into your current branch in one
step.”

Syntax:

git pull origin <branch_name>

Example:

You're on the develop branch and want the latest updates from the remote.

Run:

git pull origin develop

This is like syncing your local notebook with the shared team version — everyone gets on the same
page instantly.

git fetch – “Download remote changes without merging — gives you a

preview before you act.”

Syntax:

git fetch origin

fi
Example:

You want to see what changes are available on the remote main branch without affecting your
local copy. Run:

git fetch origin

Now, you can review them using git log origin/main — think of it like syncing emails
without reading them yet.

git merge – “Integrate another branch’s changes into your current branch.”
Syntax:

git merge <branch_name>

Example:

You're on the develop branch and want to merge in feature-login.

Run:

git merge feature-login

It’s like combining two Google Docs into one — the current one gets the new updates added in.

Now you have the complete picture:

• git fetch = grab updates silently

• git merge = bring them into your branch

• git pull = do both in one go

git pull vs git fetch + git merge

• git pull: Combines fetch + merge in one go. It downloads and merges remote changes
into your current branch immediately.

• git fetch + git merge: Fetch grabs changes without applying them. You get a
chance to review before merging manually.
GitHub Basics – Your Developer Passport to
Collaboration
In today’s world of software development,

GitHub is not just a code-hosting platform — it's the collaborative hub where code meets
conversation, creativity meets control, and DevOps pipelines begin to ow.

If Git is your version control engine, GitHub is the vehicle that takes it global. Here's your
comprehensive, real-world guide to mastering GitHub for DevOps and development teams.

Creating Repositories – Your Project’s Digital Home

Every GitHub journey begins with a repository — the place where your project lives, grows, and
evolves.

• Public Repos: Great for open-source work, community collaboration, or sharing learning
projects. Anyone can see it.

• Private Repos: Ideal for enterprise apps, pre-release projects, or con dential code. Access is
restricted.

Example: Creating a private repo for your new CI/CD pipeline scripts to share only with your
DevOps team.

Pushing Code to GitHub – Your Local Code Goes Global

Once your repository is set up, pushing your local code to GitHub is as easy as:

git remote add origin https://github.com/yourusername/

project.git

git push -u origin main

Every push is like publishing your latest chapter to a shared team book. GitHub helps track what
changed, when, and by whom — no more emailing zip les!
fi
fi
fl
Understanding GitHub UI – Navigate Like a Pro
GitHub’s interface is not just intuitive — it’s built for collaboration, review, and visibility.

Files Tab

See your code les, folders, and the project structure.

Think of this as your project dashboard — clear, organized, and accessible.

Commits Tab

View every change ever made — like a project timeline.

Want to know who xed the production bug last night at 2AM? This is where you look.

Branches Tab

Manage different versions of your project.

Feature A in one branch, Feature B in another — all safely isolated and parallel.

Pull Requests Tab

See ongoing and past PRs, team discussions, approvals, and reviews.

This is where collaboration really happens — it’s like a code negotiation table.

Forking a Repository – Create Your Copy, Build Your Way

Forking means making a copy of someone else’s repo under your account.

Use it to:

• Experiment freely without affecting the original.

• Contribute to open source by later submitting a Pull Request.

Example: Forking an open-source Kubernetes monitoring dashboard, adding a Prometheus plugin,

and sending a PR.
fi
fi
Creating and Reviewing Pull Requests (PRs)
A Pull Request (PR) is a formal way to propose changes.

When you create a PR, you’re saying:

“Here’s what I built. Can we review and merge it into the main project?”

Your team then:

• Reviews the code

• Comments inline

• Approves or requests changes

It’s the DevOps equivalent of Change Advisory Board (CAB) meetings, but lightweight and
developer-friendly.

Code Reviews – Quality Gates that Foster Learning

Code reviews in PRs are critical. They:

• Catch bugs early

• Enforce standards

• Promote shared learning

Approve
Comment

Request changes

Example:

Spotting a hard-coded IP in a deployment script before it hits production — thanks to a quick

review comment.
GitHub Issues – Track Bugs, Features & Everything Between
Issues are lightweight tickets that track:

• Bugs

• Enhancements

• Discussions

Use labels, milestones, and assignees for clarity.

Example: Raise an issue titled “CI job fails on PR merge” and assign it to the pipeline engineer
with a label: ci/CD.

GitHub Wiki – Your Project’s Built-In Knowledge Base

Every repo comes with a Wiki — a space for documentation, FAQs, SOPs, or even onboarding
notes.

Example:

Document your team's Terraform module standards or Git work ow right inside the repo — no
need for Google Docs scattered across drives.

GitHub Projects – Agile Boards, Right Where the Code Lives

GitHub Projects offer Kanban-style boards for tracking work.

Use columns like:

• To Do

• In Progress

• In Review

• Done

Link issues, PRs, and even automation rules.

Example:

Use GitHub Projects to manage sprint stories for your microservices refactor — all visible in one
dashboard.
fl
 GitHub Advanced – Supercharging DevOps
with Enterprise-Grade Git Work ows

Branch Protection Rules – Security Checkpoints for Your Codebase

Branch protection rules allow you to control how changes enter critical branches like main or
production.

Require Pull Request (PR) Reviews

Disallow Force Pushes
Require Status Checks to Pass
Enforce Signed Commits

Example:

In an Azure-based microservices project, protect your release branch to allow merges only
after two team leads review the PR and all Azure DevOps pipelines pass.

It’s like placing a security gate before production — no more rogue code sneaking in.

GitHub Actions – CI/CD Automation Without Leaving GitHub

GitHub Actions is a game-changer — it allows you to automate build, test, and deploy work ows
with just a few lines of YAML.

Understand the YAML Structure:

A work ow is de ned inside .github/workflows/ci.yml

name: CI Pipeline
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- run: echo "Hello from GitHub Actions!”

Think of it as "Infrastructure-as-Code for automation" — and it lives right next to your

application code.
fl
fi
fl
fl
Build Simple Work ows – From Hello World to Full Deploy

Want to deploy a Docker container to Azure Web App? Here's what a real-world work ow might
include:

• Checkout code

• Build Docker image

• Push to GitHub Packages or ACR

• Deploy to Azure using azure/webapps-deploy@v2

Example: Use GitHub Actions to auto-deploy your React frontend to Azure Static Web Apps
whenever a PR is merged to main.

Tip: You can trigger different jobs based on le changes, branches, or even commit messages.

Secrets Management – No More Credentials in Plain Sight

Store API keys, Azure tokens, passwords, or Docker credentials in GitHub Secrets — and use them
safely in your work ows.

env:
AZURE_TOKEN: ${{ secrets.AZURE_TOKEN }}

Example:

Save your Azure service principal credentials in GitHub Secrets to authenticate deployments
securely from Actions.

Never hard-code secrets. Think of GitHub Secrets as the vault that locks your automation down.

Triggers – When Do Actions Run?

GitHub Actions can be triggered by:

• on: push → For commits/branches

• on: pull_request → When a PR is opened or merged

• on: schedule → Like a CRON job

fl
fl
fi
fl
 • on: workflow_dispatch → Manual trigger button

Example: Schedule a nightly backup job that runs at midnight UTC using:

on:
schedule:
- cron: '0 0 * * *'

Build CI/CD work ows that are event-driven and intelligent.

Webhooks – Talk to the Outside World

Webhooks allow GitHub to send HTTP payloads to other services when speci c events occur.

Example Use Cases:

• Notify Slack when a PR is created

• Trigger Jenkins jobs

• Connect to Azure Logic Apps for automated alerts

Think of webhooks as GitHub’s “bat signal” to your external tools.

GitHub Packages – Private Package Registry, Built In

GitHub Packages allows you to store and manage Docker images, npm packages, Maven
artifacts, and more, right alongside your code.

docker push ghcr.io/youruser/your-image:latest

Example:

Build a Docker image in GitHub Actions and push it to GitHub Packages. Use it later in Kubernetes
deployments from a trusted source.

It’s secure, integrated, and tied to your GitHub identity.

fl
fi
Managing Team Permissions – Collaboration Without Chaos

In enterprise DevOps, role-based access control is crucial.

GitHub lets you assign:

• Read: View only

• Write: Push code and manage issues

• Admin: Manage settings, teams, and integrations

Example:

• Developers: Write access

• QA Engineers: Read + Issue access

• DevOps Admins: Full control for CI/CD and webhooks

Best Practice:

Use GitHub Teams and Repo Roles to enforce least-privilege access — especially for production-
facing pipelines.

Azure DevOps + GitHub: A DevOps Power

Duo for Modern Cloud Deployments
In today’s cloud-native world, integration is king.

And when GitHub’s developer- rst work ow meets Azure DevOps’ enterprise-grade CI/CD —
it unlocks seamless automation, faster delivery, and infrastructure you can trust at scale.

Let’s dive deep into how GitHub and Azure work better together to deploy apps, containers, and
infrastructure with con dence.
fi
fi
fl
Connect Azure Pipelines with GitHub Repo – CI/CD Begins at
GitHub, Deploys via Azure
You can connect any GitHub repository to Azure Pipelines in a few clicks, allowing Azure
DevOps to monitor branches and automate builds and releases.

Steps:

1. Go to Azure DevOps ➝ Pipelines ➝ New Pipeline

2. Choose GitHub as the code source

3. Authorize Azure DevOps to access your GitHub account

4. Select the repo, de ne your pipeline YAML (or classic UI)

trigger:
branches:
include:
- main

pool:
vmImage: 'ubuntu-latest'

steps:
- script: echo "Building from GitHub source!”

Use Case:

Auto-trigger CI pipeline every time a developer pushes code to main, and run tests or Docker
builds before deployment.

Think of GitHub as your source-of-truth and Azure Pipelines as your orchestration powerhouse.

Use GitHub Repos Inside Azure Repos – External Git Service

Connection
Even if you're using Azure Repos for legacy systems or large-scale governance, you can still pull
code from GitHub using a service connection.

How it Works:

• Create a Service Connection to GitHub in Project Settings > Service Connections

• Provide a Personal Access Token (PAT) from GitHub

fi
 • Con gure pipelines to clone code from GitHub

steps:

- checkout: git://GitHubRepo@main

This helps teams gradually move to GitHub or mix repositories without disrupting CI/CD ows.

Real-world case:

Teams keeping IaC code in GitHub and application code in Azure Repos — both orchestrated from
Azure Pipelines.

Continuous Deployment from GitHub to Azure App Services,

AKS, VMs – From Code Push to Production, Automatically
By combining GitHub Actions or Azure Pipelines, you can set up true continuous delivery to a
variety of Azure environments:

App Services (Web Apps)

• Push to main in GitHub

• GitHub Actions builds & deploys to Azure Web App via azure/webapps-
deploy@v2

- uses: azure/webapps-deploy@v2
with:
app-name: 'shruthi-web'
publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
package: .

AKS (Azure Kubernetes Service)

• GitHub builds Docker image, pushes to ACR

• Applies Helm or kubectl commands to update the cluster

- run: kubectl apply -f k8s/deployment.yaml

Azure VMs

• Use Azure CLI or SSH inside GitHub Actions to deploy artifacts or containers
fi
fl
Bonus: Enable deployment slots, app settings, or VM scripts as part of the work ow — your infra
is now programmable.

Deploy Infrastructure as Code (IaC) with GitHub Actions –

Automated, Declarative Azure Infrastructure
Whether you're using Terraform, Bicep, or ARM templates, GitHub Actions can be your
deployment engine for IaC.

Terraform + GitHub Actions

- uses: hashicorp/setup-terraform@v2
- run: terraform init
- run: terraform plan
- run: terraform apply -auto-approve

Authenticate via Azure CLI or service principal (store credentials in GitHub Secrets)

Bicep or ARM Templates + GitHub Actions

- uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- run: az deployment group create \
--resource-group rg-name \
--template-file main.bicep

Real-World Flow:

DevOps engineer commits changes to infra/terraform/main.tf, GitHub Action

automatically deploys updated infra to Azure within minutes.
fl
 Real-World Git Work ows & Branching
Strategies:

1. Feature Branch Work ow — Isolate, Build, Merge

Purpose: Create a separate branch for each feature, enhancement, or bug x to keep main or
develop branch clean and stable.

Work ow:

1. Checkout from develop:

git checkout -b feature/add-user-auth

2. Make code changes, commit locally.

3. Push to GitHub:
git push origin feature/add-user-auth

4. Open a Pull Request → Review → Merge to develop.

Real-World Example:

• You’re building a login module.

• You create a feature branch feature/add-login.

• Once completed and tested in Dev, it gets merged back into develop and promoted to
higher environments.

Best For: Teams practicing continuous integration with multiple developers working in parallel.
fl
fl
fl
fi
 2. Git ow Work ow — Structured Release Management
Purpose: A proven branching strategy for stable releases, especially in enterprise environments
with complex deployments.

Main Branches:

• master → Production-ready code only

• develop → Staging branch for integration

• feature/* → New features

• release/* → Final QA and hardening

• hotfix/* → Emergency xes to production

Example Flow:

# Start new feature

git checkout -b feature/payment-integration develop

# Finish & merge into develop

git checkout develop

git merge feature/payment-integration

# Prepare release

git checkout -b release/v2.1 develop

# Tag, test, stabilize...

# Release to production

git checkout master

git merge release/v2.1
git tag v2.1

Hot x

git checkout -b hotfix/critical-bug master

# Fix, then merge back into master and develop

fi
fl
fl
fi
 Best For: Regulated environments (banks, insurance, healthcare), where change control and
release cycles are crucial.

3. Trunk-Based Development — Speed + Automation

Purpose: Developers commit directly to main (aka trunk) or keep branches alive for a few
hours, encouraging fast feedback and CI/CD.

Process:

• Developers sync often.

• Short-lived branches only — ideally merged in hours.

• Feature ags are used for in-progress features.

Example:

git checkout -b fix-header-alignment

# Commit, push, open PR → merge within the day

Paired with automated GitHub Actions or Azure Pipelines to run unit tests and deploy code to
staging instantly.

Best For: Startups, microservice teams, or modern SaaS apps using CI/CD- rst strategies.

4. Managing Dev/QA/Prod Environments Using Git

Branching
Environments represent stability levels of your codebase. You can use branches to mirror
environments, making it easier to promote code safely.

Environment Branch Strategy:

• develop → Auto-deploys to Dev

• qa → Deployed to staging or UAT

• main or master → Production-ready code

Deployment Flow:

1. Dev pushes code to develop

2. After approval, merge to qa:

git checkout qa
fl
fi
 3. git merge develop

4. Final sign-off? Merge to main and deploy:

git checkout main

5. git merge qa

Each merge triggers CI/CD via GitHub Actions or Azure Pipelines → deploys to correct Azure
environment.

Best For: DevOps teams automating multi-environment deployments (App Services, AKS,
Functions, VMs).

5. Structuring Repositories – Monorepo vs Polyrepo for

Microservices
In microservices architecture, how you organize your repos in uences your CI/CD strategy,
testing, and team ownership.

Option 1: Polyrepo (Multiple Repos)

• Each microservice has its own repo

• Example: auth-service, payment-service, notification-service

Pros:

• Clear team ownership

• Isolated CI/CD pipelines

• Smaller, focused codebases

Cons:

• Dependency management is hard

• Harder to keep shared libraries in sync

Option 2: Monorepo (One Big Repo)

• All microservices live in one repo with subfolders:

/services
/auth
/payment
/notification
fl
 /common

Pros:

• Easier to manage common code

• Consistent code quality checks

• Simpli ed tooling

Cons:

• Large repo can be slower

• CI/CD pipelines need intelligent targeting

Real-World Decision:

• Polyrepo is great for teams with clear ownership and fast-moving services.

• Monorepo shines when services are tightly coupled or share core libraries, and you want
centralized control.

Mastering Advanced Git & GitHub Features:

For DevOps-Driven Engineering
As your codebase grows and your organization scales, the way you collaborate, manage security,
and structure code becomes mission-critical.

Basic Git commands get you started — but these advanced tools elevate your work ow into
enterprise-grade DevOps maturity.

Let’s unpack some game-changing features every DevOps engineer, SRE, or cloud-native
developer must know.

1. Git Submodules — “Repo inside a repo” made easy

What it is:

A submodule lets you embed a separate Git repository inside another repo as a dependency —
without copying code manually.
fi
fl
 Think of it like:

MyAppRepo/ contains → another full Git project inside libs/shared-utils/.

Real-World Use Case:

You’re building multiple microservices that share a common logging library. Instead of duplicating
it, you add it as a submodule:

git submodule add https://github.com/org/shared-utils.git

libs/shared-utils

Bonus: Each submodule tracks its own history and updates independently.

Submodules require extra care during cloning (git clone --recursive) and CI/CD. Use
them when code reuse across teams is essential.

2. Git Worktrees — Work on multiple branches without

switching
What it is:

git worktree allows you to check out multiple branches simultaneously in different folders
— without constantly switching back and forth.

Real-World Use Case:

You’re xing a production bug in main while also developing a new feature in develop.

Instead of stashing or rebasing constantly:

git worktree add ../main-worktree main

cd ../main-worktree

You now have:

• repo/ on develop

• main-worktree/ on main

Use worktrees when juggling hot xes, releases, and features in parallel — without losing your
local context.
fi
fi
 3. GitHub Enterprise vs Free GitHub — Scaling securely
GitHub Free:

• Ideal for open-source, personal projects, small teams.

• Unlimited public/private repos.

• Basic Actions, Projects, and Codespaces (with limitations).

GitHub Enterprise:

• Tailored for large organizations, regulated industries, and advanced DevOps automation.

• Key features:

◦ SSO (Single Sign-On) & role-based access control.

◦ Audit logs, IP allowlists, and enterprise-wide security policies.

◦ Advanced Security features (see below).

◦ Integration with Azure AD, GitHub Connect, and self-hosted runners.

If your organization needs compliance (SOC2, HIPAA, ISO), or you're managing 100+ engineers
across multiple teams — GitHub Enterprise gives control, visibility, and security.

4. GitHub Codespaces — Cloud-based development that

follows you
What it is:

A cloud-powered development environment right inside GitHub — no setup, no con icts.

You can launch a fully con gured VS Code editor in the browser with your repo pre-cloned and dev
containers pre-con gured.

Real-World Use Case:

You onboard a new DevOps engineer. Instead of telling them to set up Docker, Terraform CLI,
node, and Python...

They click “Open in Codespace” and get a dev-ready environment in 60 seconds.

.devcontainer/devcontainer.json

De ne everything: base image, extensions, tools.

fi
fi
fi
fl
Ideal for remote teams, training, or contributing to open-source with zero friction.

5. GitHub Advanced Security

What it includes:

A proactive, code- rst security suite integrated right into your repo:

Features:

1. Code Scanning
◦ Automatically scans code for vulnerabilities (uses CodeQL).

◦ Example: Detects SQL injection, insecure auth logic, etc.

◦ Alerts right inside PRs.

2. Secret Scanning
◦ Finds accidentally committed secrets (e.g., AWS keys, Slack tokens).

◦ Can block pushes that contain secrets in GitHub Enterprise.

3. Dependency Review
◦ Flags vulnerable packages in PRs.

◦ Works with npm, pip, Maven, Gradle, etc.

Real-World DevOps Usage:

• Every new PR triggers a scan.

• If a junior dev accidentally pushes a secret:

◦ GitHub blocks it

◦ Sends an alert

◦ You rotate the key — fast.

Combine GitHub Actions with Advanced Security to automate secure CI/CD pipelines that
catch issues before code hits production.
fi