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 "[e-mail]"
   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.