DevOps · Git Cheatsheet

The 20 Git Commands
Every Fresher Needs

Nobody will sit with you on day two and explain Git. They'll assume you know it. These are the exact 20 commands used in real dev teams — organized by when you'll actually need them, with honest warnings about what breaks things.

Start Learning ↓ Quick Reference →

20 commands explained

Real team workflow

5 mistakes to avoid

20CommandsDaily to Pro level

4GroupsDaily · Team · Rescue · Pro

5MistakesFreshers always make

8Workflow StepsReal team PR cycle

~45mRead TimeFully covered

Mental Model First — Git's 4 Places

Before the commands, understand this one thing: Git tracks your code in 4 places. Every single git command just moves code between these 4 buckets. That's it. Once this clicks, nothing confuses you.

Place 01

Working Directory

The files on your laptop right now. Untracked by git until you add them.

git add →

Place 02

Staging Area

Files marked "ready to commit." Your waiting room before saving to history.

git commit →

Place 03

Local Repository

Commits saved on your machine only. Your full history, offline.

git push →

Place 04

Remote Repository

GitHub / GitLab / Bitbucket. Shared with the team. The source of truth.

← git pull

add moves files to staging → commit moves staging to local → push moves local to remote → pull brings remote back to local. That's the entire loop.

⌨️The 20 Commands

These 5 commands are 80% of git usage. Master these before anything else. You'll run them dozens of times every day.

git clone

Copy a repository to your machine

Downloads the entire repo — all branches, all history, all files. You'll run this exactly once per project.

bash

git clone https://github.com/company/project.git
cd project

Common mistake: running git clone inside another git repo. Always cd out first.

git status

What changed? What's staged?

Your most-used command. Shows which files you've modified, which are staged, and which branch you're on.

bash

git status

Run this before every commit. Every single time. Git gives you hints — status tells you exactly what to do next.

git add

Stage changes for the next commit

Staging = telling git "include these in the next commit". Moves files from Working Directory → Staging Area.

bash
# Stage one specific file
git add src/login.js

# Stage everything in current directory
git add .

# Stage only parts of a file (interactive)
git add -p

Prefer git add <file> over git add . — the dot can accidentally stage secrets, debug files, or node_modules.

git commit

Save a permanent snapshot

A commit is a permanent snapshot saved forever in git history. Moves code from Staging Area → Local Repository.

bash
# Commit with a message
git commit -m "fix login redirect bug"

# Commit all tracked changes (skip staging)
git commit -am "fix login redirect bug"

Message style: short, imperative mood. "fix bug" not "fixed a bug". Think: "If applied, this commit will fix bug."

git push

Upload commits to remote

Uploads your local commits to GitHub/GitLab. Until you push, your work exists only on your laptop.

bash
# Push current branch
git push

# First push of a new branch (-u sets tracking)
git push -u origin feature/login-fix

The -u flag sets up tracking. After the first push with -u, you can just run git push with no arguments.

Once you're collaborating with others, these become critical. Branching, merging, and staying in sync are the core of team git.

git pull

Download + merge from remote

Pull = fetch + merge. Downloads new commits from GitHub and merges them into your current branch.

bash

git pull

Golden rule: always git pull before starting new work. Otherwise you'll commit on top of stale code and hit merge conflicts.

git branch

Create and manage branches

A branch is a movable pointer to a commit. Branches are cheap — create one for every feature, bugfix, and experiment.

bash
# List all local branches
git branch

# Create a new branch (doesn't switch)
git branch feature/dark-mode

# Delete a branch (only if merged)
git branch -d feature/old-work

# Force delete (dangerous — unmerged changes lost)
git branch -D feature/abandoned

git checkout / git switch

Switch branches

Switch to an existing branch, or create a new one and switch in a single command.

bash
# Classic syntax
git checkout main
git checkout -b feature/search-filter

# Modern syntax (git 2.23+) — preferred
git switch main
git switch -c feature/search-filter

Both still work. git switch is clearer because it only does one thing — switch branches.

git merge

Combine a branch into current

Takes the changes from one branch and applies them to another. This is how your feature code gets into main.

bash

# Merge feature into main
git checkout main
git pull          # always pull before merging
git merge feature/dark-mode

Merge conflicts happen when two branches changed the same lines. Git pauses and asks you to pick which version wins. Don't panic — just edit the conflict markers and commit.

git log

See commit history

View the history of commits, branches, and merges. The one-line graph view is the most useful format.

bash
# Full log
git log

# One line per commit (most useful)
git log --oneline

# Graph showing all branches
git log --oneline --graph --all

# Last 5 commits only
git log -5

# Add this alias to .gitconfig:
# lg = log --oneline --graph --all --decorate

Every fresher hits these moments. Commit this tab to memory — these commands save you when things go sideways.

git diff

See exactly what changed

Shows line-by-line what you've changed. Run this before every commit to make sure you're committing what you think.

bash
# Unstaged changes
git diff

# Staged changes (what's about to be committed)
git diff --staged

# Compare two branches
git diff main feature/login

# Compare two commits
git diff abc123 def456

git stash

Save work temporarily

Saves your uncommitted changes and cleans the working directory. Great for quick context switches.

bash
# Save current changes
git stash
git stash push -m "wip on login bug"

# List all stashes
git stash list

# Bring back the most recent stash
git stash pop

# Bring back a specific stash
git stash apply stash@{1}

Classic scenario: tech lead says "quick hotfix on prod." You have uncommitted work. stash it, fix prod, pop the stash, continue.

git reset

Undo commits (3 modes)

Moves HEAD backwards in history. Three modes with very different consequences — understand them before using.

bash
# Soft: undo commit, keep changes STAGED
git reset --soft HEAD~1

# Mixed (default): undo commit, keep changes UNSTAGED
git reset HEAD~1

# Hard: undo commit, DELETE changes FOREVER
git reset --hard HEAD~1

# HEAD~3 means "three commits back"

Never --hard reset work you haven't pushed unless you're sure. It's permanent. Use on local branches only.

git revert

Undo a commit safely (keeps history)

Creates a new commit that undoes the changes. History stays intact. This is the safe way to undo code already pushed to a shared branch.

bash

git revert abc123

Rule of thumb: revert on shared/pushed branches. reset only on your local, unpushed commits.

git restore

Discard local changes

Throw away changes to a file. The modern replacement for git checkout -- file.

bash
# Discard unstaged changes to one file
git restore src/login.js

# Discard ALL unstaged changes (careful!)
git restore .

# Unstage a file (keep the changes, just un-add)
git restore --staged src/login.js

Once you're comfortable with the basics, these make you look like a senior developer. Rebase and reflog are the two most powerful.

git rebase

Rewrite history for a clean linear log

Takes your commits and replays them on top of a new base — producing a linear history without messy merge commits.

bash
# Rebase feature branch onto latest main
git checkout feature/login
git rebase main

# Interactive rebase — squash, reorder, edit 5 commits
git rebase -i HEAD~5
# Options: pick / squash / reword / drop / edit

Golden rule: never rebase commits already pushed to a shared branch. Rebase rewrites history — it breaks everyone else's copy.

git fetch

Download without merging

Downloads new commits from remote without touching your working directory. Inspect what changed before merging.

bash
git fetch          # fetch all remotes
git fetch origin   # fetch from origin specifically

# Then inspect before merging
git log HEAD..origin/main --oneline

Think of fetch as the "safe pull". Use it when you want to see what's changed without affecting your work.

git cherry-pick

Copy one specific commit

Takes one commit from any branch and applies it to your current branch — without merging the whole branch.

bash

git cherry-pick abc123

# Cherry-pick a range of commits
git cherry-pick abc123..def456

Classic use: a fix was committed to the wrong branch. Cherry-pick it onto the right one without moving everything else.

git tag

Mark a release

Tags mark important commits — usually releases. Unlike branches, tags don't move.

bash
# Annotated tag (preferred — includes author + message)
git tag -a v1.2.0 -m "Release 1.2.0"

# Push tags (NOT automatic — must be explicit)
git push --tags

# List all tags
git tag

git reflog

Your career safety net

Git's secret log of every change to HEAD — including resets, rebases, and deleted branches. Even if you --hard reset and "lost" work, reflog finds it.

bash
# Show the full reflog
git reflog

# Find the lost commit in the output, then recover:
git checkout abc123
# or restore your entire branch to that point:
git reset --hard abc123

Reflog entries live for 90 days by default. If you've lost work in git, check reflog first. Almost always it's still there.

The Team Workflow — Putting It All Together

This is the workflow you'll follow 99% of the time at your first job. Memorize this sequence.

Start from latest main

git checkout main && git pull

Always pull first. Never branch off stale code.

Create a feature branch

git checkout -b feature/user-profile

Never commit directly to main. One branch per feature or bugfix.

Make changes, check what changed

git status && git diff

Verify exactly what you've changed before staging anything.

Stage and commit

git add src/profile.js && git commit -m "add user profile page"

Stage specific files. Write a meaningful commit message.

Push to remote

git push -u origin feature/user-profile

First push uses -u. After that, just git push.

Open a Pull Request on GitHub

GitHub UI → Compare & pull request

Request a code review. Describe what you built and why.

If main moved forward during review

git fetch && git rebase origin/main && git push --force-with-lease

Rebase keeps history clean. --force-with-lease is safer than --force.

After PR is merged — clean up

git checkout main && git pull && git branch -d feature/user-profile

Delete the local branch. Start the cycle again for the next feature.

Common Mistakes Freshers Make

These are the 5 mistakes that cause the most pain. Avoid them from day one.

Mistake 01

Committing directly to main

Main is the production branch. Any bad commit there affects everyone on the team immediately.

Always work on a feature branch. Main is sacred.

Mistake 02

Using git push --force

Force push rewrites history. If someone else pulled that branch, their local copy becomes invalid and corrupted.

Use --force-with-lease instead — it fails safely if someone else pushed.

Mistake 03

Committing secrets & API keys

Once committed, they live in git history forever — even if you delete the file. Anyone who clones the repo can find them.

Add .gitignore before your first commit. Use environment variables for secrets.

Mistake 04

Giant, unfocused commits

"fix 5 bugs and add a feature" in one commit. Impossible to review, impossible to revert one part of it.

One logical change per commit. Small commits are easier to review and revert.

Mistake 05

Vague commit messages

"fix", "update", "wip" — useless. Six months later nobody knows what you did, including you.

"fix null pointer in login redirect when cookie expired" — be specific.

.gitignore — Non-Negotiable

Create a .gitignore at the repo root before your first commit. It tells git which files to never track. GitHub maintains official templates at github.com/github/gitignore — always start from one of those.

.gitignore
# Dependencies
node_modules/
vendor/
__pycache__/
*.pyc

# Environment & Secrets
.env
.env.local
.env.production
*.key
*.pem
secrets.json

# IDE
.vscode/
.idea/
*.swp
*.swo

# Build Output
dist/
build/
*.log
*.out

# OS Files
.DS_Store
Thumbs.db
desktop.ini

Quick Reference — All 20 Commands

#	Command	What It Does	Group
01	`git clone <url>`	Copy a repo to your machine	Daily
02	`git status`	What's changed? What's staged?	Daily
03	`git add <file>`	Stage a file for commit	Daily
04	`git commit -m "msg"`	Save a snapshot to local history	Daily
05	`git push`	Upload commits to remote	Daily
06	`git pull`	Download + merge from remote	Team
07	`git branch`	List / create / delete branches	Team
08	`git checkout -b <name>`	Create + switch to new branch	Team
09	`git merge <branch>`	Combine a branch into current	Team
10	`git log --oneline --graph`	See commit history visually	Team
11	`git diff`	See unstaged changes line by line	Rescue
12	`git stash`	Save work temporarily	Rescue
13	`git reset --soft HEAD~1`	Undo last commit, keep changes staged	Rescue
14	`git revert <sha>`	Safely undo a pushed commit	Rescue
15	`git restore <file>`	Discard local file changes	Rescue
16	`git rebase main`	Replay commits on top of main	Pro
17	`git fetch`	Download without merging	Pro
18	`git cherry-pick <sha>`	Copy one commit to current branch	Pro
19	`git tag -a v1.0.0`	Mark a release	Pro
20	`git reflog`	Recover lost commits (your safety net)	Pro

What to Learn Next & Resources

Once you're comfortable with the 20 commands, go deeper in this order: git object model → interactive rebase → .gitconfig setup → merge conflict practice.

Free Book Pro Git The official comprehensive guide. Chapters 1–3 are must-reads. Everything else is reference. Interactive Learn Git Branching Visual, game-like tutorial. The best way to understand branching and rebasing intuitively. Quick Recipes Oh Shit, Git!?! Practical fixes for when you mess up. Bookmark this — you will need it. Workflow GitHub Flow The branching workflow used by most teams. Simple, effective, industry-standard. Reference Git Documentation Official docs for every command. Use git help <command> or search here. Templates GitHub .gitignore Templates Official ignore templates for every language and framework. Always start from here.

One Final Rule: When in doubt, git status.

Git gives you hints. Status will usually tell you exactly what to do next. Before any scary command — check status. Before committing — check status. Before pushing — check status. That one habit prevents 80% of fresher mistakes.

Ready to interview? Git comes up more than you think.

DSA, Python, SQL, and OOP — 200+ interview questions tagged for FAANG and startups, with progress tracking in your browser.

Interview Prep Hub →

← Home Interview Q&A →

The 20 Git Commands Every Fresher Needs

The 20 Git Commands
Every Fresher Needs