Guides

Git Basics for DevOps Beginners

By Ravindra Bagale, DevOps trainer · LinkedIn · Published: 30 September 2026 · Last updated: 30 September 2026

Read this guide in: English · मराठी · हिंदी

Why do we need Git? Because there is a real problem between developers and operations when history is a zip. Developers change code on the laptop. Operations — the employee on the server side — copies “whatever build arrived last.” Friday night nobody knows which file is live. Git joins both sides: every save is a commit with who, when and why, then git push puts the same history on GitHub.

Friends, do not start with twenty Git commands. First understand the mystery-build fight. Then add, commit, push will feel natural.

Language: English · मराठी · हिंदी

Why do we need Git?

Developers and operations both care about the product, but without shared history they fight:

1. Developers finish a change and say “done.”
2. Operations on the server side needs a file they can trust — not three zips with different names.
3. When production breaks, both need: who changed what, and when?

That is why beginners learn Git before pipelines.

What does operations have to do with Git?

1. Operations is the server-side employee (or team).
2. Their day includes deploy, restart, logs, rollback.
3. Without Git they guess which zip to copy. With Git they deploy a known commit.

What is the problem? Suppose we are…

Suppose we are building Instagram (like updates)

Suppose your team ships Instagram-style profile badges.

1. Monday — developer A emails profile-final.zip.
2. Developer B also edits and WhatsApps profile-FINAL-v2.zip.
3. Wednesday — operations (server-side) copies “the latest” by guesswork to production.
4. Friday night — profile page wrong. “Worked on my laptop.” Nobody knows which zip is live.

Suppose we are working at Netflix and we are giving updates

Suppose Netflix pushes many small home-screen fixes a week. If history is only zip names in chat, operations cannot roll back to “Tuesday’s good build” with confidence.

Suppose you are working in Infosys on a client project

Suppose two Infosys developers email builds to the client operations team. Client asks: which attachment is approved? Without Git + review, release day is a war room.

How Git answers that same fight

1. Verify Git: git --version (install from the official Git site if missing).
2. Set identity once: git config --global user.name and user.email.
3. mkdir myapp && cd myapp then git init — hidden .git is the history database.
4. Write README.md → git add README.md → git commit -m "Add README".
5. Empty GitHub repo → git remote add origin <URL> → git push -u origin main.

Now developers and the server-side person share one story.

Commands on the laptop

git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
mkdir myapp && cd myapp
git init
git branch -M main
echo "# myapp" > README.md
git status
git add README.md
git commit -m "Add README"
git log --oneline
git remote add origin <REPO_URL>
git push -u origin main

Working tree = files on disk. Staging = what the next commit includes. Repository = saved commits. Read git status twice; commit once.

What you should see

1. git log --oneline shows hash + message.
2. After push, GitHub lists your files.
3. Clean tree: git status says nothing to commit, working tree clean.

Common errors — story pain then fix

Everyday commands after the first save

git status
git diff
git diff --staged
git log --oneline -5
git restore FILE
git rm FILE

Samajla ka? Why Git = developer vs operations mystery-build fight; operations needs a known commit; Instagram / Netflix / Infosys “suppose” shows the mess; add → commit → push shares history. Five tiny commits tonight.