Git & GitHub for DevOps - The Complete Hands-On Guide (Week 4)

Linkedin Profile: https://www.linkedin.com/in/ashish360/

Git and GitHub are the backbone of modern DevOps workflows. Every CI/CD pipeline, Infrastructure-as-Code repo, GitOps setup, and production deployment relies on Git for version control and collaboration.

This guide is written from a DevOps engineer’s perspective, not just “how Git works”, but how Git is actually used in real systems.

Table of Contents

What is Version Control & Why DevOps Needs It

Git vs GitHub (Clear Difference)

Git Core Concepts (Repo, Commit, Branch, Merge)

Git Installation & Configuration

Git Repository Lifecycle

Working Directory, Staging Area & Repository

Essential Git Commands (with definitions & examples)

Branching Strategies for DevOps

Merging & Conflict Resolution

Staging & Stashing

Undoing Changes (Reset, Revert, Amend, Reflog)

Tags & Releases

Git Ignore, Attributes & Cleanup

GitHub Basics (Remote, SSH, Push, Pull)

Forks, Pull Requests & Open-Source Flow

Advanced Git (Rebase, Cherry-Pick, Hooks, LFS)

Git in CI/CD & DevOps Pipelines

Best Practices for DevOps Engineers

1. What is Version Control?
   
   Definition:
   
   Version control is a system that tracks changes in files over time, allowing you to review history, collaborate safely, and roll back when needed.
   
   Why DevOps Needs Git
   
   Infrastructure code must be traceable
   
   CI/CD pipelines rely on Git events
   
   Rollbacks must be fast and safe
   
   Teams work in parallel without conflicts




2. Git vs GitHub
   
   Git
   
   GitHub
   
   Distributed version control system
   
   Hosting platform for Git repositories
   
   Runs locally
   
   Cloud-hosted
   
   Tracks changes
   
   Enables collaboration
   
   CLI-based
   
   Web UI + APIs
   
   Created in 2005
   
   Launched in 2008

Important:

👉 Git works without internet

👉 GitHub is only used for push, pull, PRs, CI/CD

1. Core Git Concepts
   Repository
   A project folder tracked by Git.
   Commit
   A snapshot of changes with a unique hash.
   Branch
   An independent line of development.
   Merge
   Combining changes from one branch into another.
   3.1 Understanding the Git Three-Stage Workflow (Easy Explanation)
   This diagram shows how files move step-by-step inside Git, from your computer to permanent history.

A. Working Directory

By Ashish - Learn-in-Public DevOps Journey (Week 4)

Git and GitHub are the backbone of modern DevOps workflows. Every CI/CD pipeline, Infrastructure-as-Code repo, GitOps setup, and production deployment relies on Git for version control and collaboration.

This guide is written from a DevOps engineer’s perspective, not just “how Git works”, but how Git is actually used in real systems.

Table of Contents

What is Version Control & Why DevOps Needs It

Git vs GitHub (Clear Difference)

Git Core Concepts (Repo, Commit, Branch, Merge)

Git Installation & Configuration

Git Repository Lifecycle

Working Directory, Staging Area & Repository

Essential Git Commands (with definitions & examples)

Branching Strategies for DevOps

Merging & Conflict Resolution

Staging & Stashing

Undoing Changes (Reset, Revert, Amend, Reflog)

Tags & Releases

Git Ignore, Attributes & Cleanup

GitHub Basics (Remote, SSH, Push, Pull)

Forks, Pull Requests & Open-Source Flow

Advanced Git (Rebase, Cherry-Pick, Hooks, LFS)

Git in CI/CD & DevOps Pipelines

Best Practices for DevOps Engineers

1. What is Version Control?
   
   Definition:
   
   Version control is a system that tracks changes in files over time, allowing you to review history, collaborate safely, and roll back when needed.
   
   Why DevOps Needs Git
   
   Infrastructure code must be traceable
   
   CI/CD pipelines rely on Git events
   
   Rollbacks must be fast and safe
   
   Teams work in parallel without conflicts




2. Git vs GitHub
   
   Git
   
   GitHub
   
   Distributed version control system
   
   Hosting platform for Git repositories
   
   Runs locally
   
   Cloud-hosted
   
   Tracks changes
   
   Enables collaboration
   
   CLI-based
   
   Web UI + APIs
   
   Created in 2005
   
   Launched in 2008

Important:

👉 Git works without internet

👉 GitHub is only used for push, pull, PRs, CI/CD

1. Core Git Concepts
   Repository
   A project folder tracked by Git.
   Commit
   A snapshot of changes with a unique hash.
   Branch
   An independent line of development.
   Merge
   Combining changes from one branch into another.
   3.1 Understanding the Git Three-Stage Workflow (Easy Explanation)
   This diagram shows how files move step-by-step inside Git, from your computer to permanent history.

A. Working Directory

This is your actual project folder on your system.

You write code here

You edit files here

Git is aware of changes but hasn’t saved them yet

Example:

vim app.py

At this stage, Git sees changes but nothing is recorded.

B. Staging Area

The staging area is like a preview or waiting room.

You tell Git which changes you want to save

Only selected files move forward

Command used:

git add app.py

Now Git knows:

“This file should be included in the next commit.”

This gives you control over what goes into version history.

C. Repository

The repository is where Git permanently stores snapshots of your project.

Once committed, changes become part of history

Each commit has a unique ID (hash)

Command used:

git commit -m "Add initial app logic"

Now the change is saved forever in Git history.

D. How the Flow Works Together

Working Directory → Staging Area → Repository

edit add commit

git add moves files from working directory → staging

git commit moves files from staging → repository

3.2 Understanding Local vs Remote Git Workflow (Easy Explanation)

This diagram shows how your code moves between your system (local) and GitHub (remote) using common Git commands.

Think of it as two worlds:

Local → Your laptop / system

Remote → GitHub repository

🔹 Local Side (Your System)

a. Working Directory

This is where you actually write and edit code.

Files are modified here

Git is aware of changes but hasn’t saved anything yet

Example:

vim app.py

b. Staging Area

The staging area is where you prepare changes for saving.

Command:

git add app.py

This tells Git:

“I want this file to be part of the next commit.”

c. Local Repository

This is Git’s local database of commits.

Command:

git commit -m "Add app logic"

Now the change is saved permanently on your system with a commit ID.

🔹 Remote Side (GitHub)

d. Remote Repository

This is the repository hosted on GitHub / GitLab / Bitbucket.

It allows:

Collaboration

Backup

CI/CD triggers

Code reviews

e. How Code Moves Between Local & Remote

👉 Push (Local → Remote)

git push origin main

Sends your local commits to GitHub

Makes your code visible to teammates

Triggers pipelines (CI/CD)

👈 Pull (Remote → Local)

git pull origin main

Brings latest changes from GitHub to your system

Keeps your local code updated

f. Checkout (Move Between States)

git checkout branch-name

Switches branches

Can restore files from commits

Moves code back into your working directory

🧠 Simple Flow Summary

Working Directory

↓ git add

Staging Area

↓ git commit

Local Repository

↓ git push

Remote Repository (GitHub)

↑ git pull

3.3 Understanding the Gitflow Workflow (Easy Explanation)

This diagram shows how professional teams manage code using multiple branches instead of pushing everything directly to main / master.

Gitflow is designed to:

Keep production code stable

Allow parallel development

Handle releases and hotfixes safely

🧠 Big Picture First

Think of Gitflow like a road system:

Master (Main) → Production highway

Develop → Integration road

Feature branches → Side streets (new work)

Release branch → Final inspection lane

Hotfix branch → Emergency lane

A. Master Branch (Production)

This branch always contains stable, production-ready code

Every commit here is usually tagged with a version (e.g., v1.0, v2.2)

No direct development happens here

In the diagram:

Master runs at the top

Tags like 0.1, 0.2, 1.0 represent production releases

B. Develop Branch (Main Development Line)

This is where all completed features come together

It represents the next release in progress

Developers do not push features directly to master

In the diagram:

Develop runs below master

Features are merged into develop first

C. Feature Branches (New Work)

Created from develop

Used to build new features

Once finished, merged back into develop

Example:

git checkout -b feature-login develop

In the diagram:

Feature branches are shown at the bottom

They merge back into develop using:

git merge feature-branch

After merging:

git branch -d feature-branch

D. Release Branch (Preparing for Production)

Created when the product is almost ready

Only bug fixes, version bumps, and final testing happen here

No new features allowed

Example:

git checkout -b release/1.0 develop

In the diagram:

Release branch sits between develop and master

After testing, it is merged into:

master (for production)

develop (to keep history consistent)

E. Hotfix Branch (Emergency Fixes)

Used when production is broken

Created directly from master

Fixes critical bugs quickly

Example:

git checkout -b hotfix/0.2 master

In the diagram:

Hotfix branch jumps directly from master

After fixing:

Merged back into master

Also merged into develop

This ensures:

Emergency fixes don’t get lost in future releases.

F. Merge Flow Summary

Feature → Develop

git merge feature-x

Release → Master + Develop

git merge release

Hotfix → Master + Develop

git merge hotfix

🏷️ Tags (Versions)

Tags mark release points

Example:

git tag -a v1.0 -m "Production release"

In the diagram:

Tags appear on the master branch

They represent what is deployed in production

3.4 Understanding This Gitflow Diagram (Very Easy Explanation)

This diagram shows how code moves over time when a team follows the Gitflow branching strategy.

👉 The vertical direction represents time (top = older, bottom = newer).

👉 Each vertical lane is a branch.

👉 Dots are commits.

👉 Arrows show merges between branches.

a. Master Branch (Rightmost – Production)

This is the production branch

Whatever is here is live for users

Every production release is tagged (e.g. 0.1, 0.2, 1.0)

In the diagram:

Blue dots on the right = production releases

Tags show version numbers

🔒 Rule:

Never develop directly on master

b. Develop Branch (Center – Integration Branch)

This is where all completed features come together

Represents the next upcoming release

Always ahead of master

In the diagram:

Yellow dots = commits on develop

Features and bugfixes merge into develop first

Think of develop as:

“What will go live in the next version”

c. Feature Branches (Left Side – New Work)

Created from develop

Used to build new features

Each feature is isolated so it doesn’t break others

In the diagram:

Pink dots = feature branch commits

Multiple feature branches can exist at the same time

Once a feature is done → merged into develop

Example:

git checkout -b feature-login develop

After completion:

git merge feature-login

d. Release Branch (Green – Final Preparation)

Created when features are complete

Only bug fixes, version updates, and final testing

No new features allowed here

In the diagram:

Green dots = release branch

Label “Start of release branch for 1.0” marks release creation

After testing, it is merged into:

master → production

develop → keep history consistent

This ensures:

✔ Production is stable

✔ Develop doesn’t miss fixes

e. Hotfix Branch (Emergency Fixes)

Created directly from master

Used when production breaks

Fixes are urgent and small

In the diagram:

Red dot = hotfix

Created after a production tag (0.1)

After fixing:

Merged into master

Also merged into develop

This avoids:

❌ Fix existing only in production

❌ Losing fixes in future releases

f. Why Merges Go Back to Develop

Notice arrows going back into develop.

This is important because:

Any fix done in release or hotfix must be included in future versions

Develop always stays complete and updated

g. Version Tags Explained

Tags like:

0.1

0.2

1.0

Represent:

Exact production snapshots

Used for rollback, auditing, deployments

Example:

git tag -a v1.0 -m "Production release"

h. Simple Flow Summary

Feature → Develop

Develop → Release

Release → Master

Hotfix → Master + Develop

Tag → Production version

1. Install & Configure Git
   
   git --version
   
   Purpose: Verify Git installation
   
   git config --global user.name "Ashish"
   
   git config --global user.email "[email protected]"
   
   Purpose: Set author identity for commits




2. Initialize a Repository
   
   git init
   
   Purpose: Create a new Git repository
   
   Creates a hidden .git/ directory
   
   git status
   
   Purpose: Shows current state of repo (tracked, staged, untracked)




3. Working Directory → Staging → Repository
   
   Stage
   
   Meaning
   
   Working Directory
   
   Files you edit
   
   Staging Area
   
   Files selected for commit
   
   Repository
   
   Permanent commit history




4. Essential Git Commands (With Definitions)
   
   Create Files
   
   touch file.txt
   
   Creates a new file

Stage Files

git add file.txt

Stages a specific file

git add .

Stages all changes

Commit Changes

git commit -m "Initial commit"

Saves staged changes as a snapshot

View History

git log

Shows full commit history

git log --oneline

Compact commit view

git show

Shows changes of a specific commit

1. Branching (DevOps Critical)
   
   git branch
   
   Lists branches
   
   git branch feature-login
   
   Creates new branch
   
   git checkout feature-login
   
   Switches branch
   
   git checkout -b feature-api
   
   Create + switch branch
   
   git branch -d feature-login
   
   Deletes merged branch
   
   git branch -D feature-login
   
   Force delete branch




2. Merging Branches
   
   git merge feature-login
   
   Merges branch into current branch
   
   Merge Types
   
   Fast-forward → No divergence
   
   No-ff → Always creates merge commit
   
   Squash → Combines commits
   
   git merge --abort
   
   Cancels a failed merge




3. Staging & Stashing
   
   Stash Changes
   
   git stash
   
   Temporarily saves uncommitted work
   
   git stash list
   
   Lists stashes
   
   git stash apply
   
   Restores stash
   
   git stash pop
   
   Apply + remove stash




4. Undoing Changes Safely
   
   Git Reset (Local Only)
   
   git reset --soft
   
   Moves HEAD, keeps staged
   
   git reset --mixed
   
   Unstages changes (default)
   
   git reset --hard
   
   Deletes changes (dangerous)

Git Revert (Safe for Public Repos)

git revert

Creates a new commit that undoes changes

Amend Last Commit

git commit --amend

Edits last commit

Reflog (Recovery Tool)

git reflog

Shows all HEAD movements — lifesaver for recovery

1. Tags & Releases
   
   git tag v1.0
   
   Creates lightweight tag
   
   git tag -a v1.1 -m "Release v1.1"
   
   Creates annotated tag
   
   git show v1.1
   
   Shows tagged commit




2. Ignoring & Cleaning Files
   
   .gitignore
   
   *.log
   
   node_modules/
   
   .env
   
   Prevents files from being tracked

Clean Untracked Files

git clean -n

Dry run

git clean -f

Deletes untracked files

1. GitHub Basics
   Clone Repo
   git clone
   Downloads full repository

Set Remote

git remote add origin

Links local repo to GitHub

git remote -v

Verifies remotes

Push & Pull

git push origin main

Uploads changes

git pull origin main

Fetch + merge changes

1. Forks & Pull Requests
   
   Fork → Personal copy of repo
   
   Clone → Local copy
   
   Pull Request → Request to merge code
   
   Standard Open-Source Flow:
   
   Fork repo
   
   Clone fork
   
   Create feature branch
   
   Push changes
   
   Open PR




2. Advanced Git (DevOps Focus)
   
   Rebase
   
   git rebase main
   
   Rewrites history (cleaner logs)

Cherry-Pick

git cherry-pick

Applies a specific commit

Hooks

Scripts triggered on Git events (pre-commit, post-merge)

Git LFS

Handles large files efficiently

1. Git in CI/CD
   
   Git push triggers pipelines
   
   Branch rules protect production
   
   Tags trigger releases
   
   GitOps tools watch Git state




2. Best Practices for DevOps Engineers
   
   Small, meaningful commits
   
   Never rewrite public history
   
   Protect main branch
   
   Use PR reviews
   
   Tag releases
   
   Automate via pipelines

Final Note

Git is not just a tool - it’s the control system of modern DevOps.

Mastering Git means mastering collaboration, automation, and safe deployments.

Thanks for following Week 4 of my Learn-in-Public DevOps journey.