Git: Zero to Hero

From your first commit to confident branching, rebasing, and undoing mistakes without fear. Git is the foundation every other tool in this toolkit sits on — GitOps, CI/CD, and IaC all assume you're fluent here. Work top to bottom, or jump to a part.

The journey:

1. The mental model — three trees
2. Your first repository and commit
3. Branching and merging
4. Working with remotes
5. Rebase vs merge
6. Undoing things safely
7. Inspecting history
8. A pull-request workflow that scales
9. Production habits

---

Prerequisites

Confirm and set your identity before your first commit — Git stamps it on everything:

git --version
git config --global user.name  "Your Name"
git config --global user.email "[email protected]"
git config --global init.defaultBranch main

---

Part 1 — The mental model: three trees

Git isn't a pile of file copies — it's a graph of commits, each a full snapshot with a parent. The magic is that most work happens across three areas:

The loop is always: edit → add (stage) → commit (snapshot). Staging is what lets you commit some of your changes and not others — a feature, not a chore.

---

Part 2 — Your first repository and commit

git init myproject && cd myproject     # create a repo
echo "# My Project" > README.md
git status                             # see untracked/modified files
git add README.md                      # stage it
git commit -m "Add README"             # snapshot it
git log --oneline                      # your history, one line per commit

git status is the command you'll run most — it always tells you which of the three trees your changes are in and what to do next. Add a .gitignore early so build output, node_modules/, and secrets never get committed.

---

Part 3 — Branching and merging

A branch is just a movable pointer to a commit — cheap to create, cheap to throw away. Do all real work on branches, never directly on main.

git switch -c feature/login      # create + switch to a branch (new syntax)
# ...edit, add, commit...
git switch main                  # back to main
git merge feature/login          # bring the work in
git branch -d feature/login      # delete the merged branch

If main didn't move while you worked, Git does a fast-forward (just advances the pointer). If it did, Git creates a merge commit joining both lines of history.

---

Part 4 — Working with remotes

A remote is a copy of the repo somewhere else (GitHub, GitLab, a server). origin is the conventional name for your main one.

git remote add origin [email protected]:you/myproject.git
git push -u origin main          # push + set upstream (only need -u once)

git clone [email protected]:you/other.git   # copy an existing repo
git fetch                        # download remote changes, don't merge
git pull                         # fetch + merge (or --rebase) in one step

fetch vs pull: fetch updates your view of the remote without touching your work — safe any time. pull also merges it into your branch. When in doubt, fetch and look before you merge.

---

Part 5 — Rebase vs merge

Both integrate one branch into another; they differ in the history they produce.

git switch feature
git rebase main        # replay your commits on top of the latest main

• Merge preserves exactly what happened, with a merge commit — truthful but bushy.
• Rebase rewrites your branch's commits onto a new base, giving a clean, linear history — but it changes commit hashes.

The golden rule: never rebase commits you've already pushed and others may have based work on. Rebase your local, un-pushed branch to tidy it before opening a PR; merge to integrate shared branches.

Interactive rebase is the power tool for cleaning up a messy branch:

git rebase -i main     # squash, reorder, reword, or drop commits before review

---

Part 6 — Undoing things safely

Almost nothing in Git is truly lost — know which tool matches the situation:

revert vs reset: use revert for anything already shared (it's non-destructive and safe on shared history); use reset only on local, un-pushed commits. When you think you've lost work, git reflog almost always finds it.

---

Part 7 — Inspecting history

git log --oneline --graph --all      # the whole branch topology, visually
git show <sha>                       # what a specific commit changed
git diff main..feature               # difference between two branches
git blame <file>                     # who last touched each line (and in which commit)
git bisect start                     # binary-search history to find a bug's origin

git bisect is underused gold: mark a known-good and known-bad commit and Git checks out the midpoint repeatedly until it pinpoints the commit that introduced a regression.

---

Part 8 — A pull-request workflow that scales

This is how teams actually ship:

git switch -c fix/timeout main       # branch from up-to-date main
# ...work, commit in small logical chunks...
git push -u origin fix/timeout       # push the branch
# open a Pull/Merge Request in the UI → review → CI runs → merge

Conventions that keep it sane:

• Small, focused branches — one concern per PR; easier to review and revert.
• Write good commit messages — a concise subject line, then why in the body. History is documentation.
• Rebase your branch on main before merge to resolve conflicts on your side, not in the merge.
• Let CI gate the merge — tests, lint, and security checks run on the PR (see the GitHub Actions tutorial).
• Protect main — require reviews and green CI; no direct pushes.

---

Part 9 — Production habits

• Commit early, commit often, in logical units — small commits are easy to review, revert, and bisect.
• Never commit secrets. Use .gitignore and a secret scanner; a leaked key in history stays there until you rewrite it.
• main is always deployable. Feature work lives on branches behind review.
• Pull with rebase (git config --global pull.rebase true) to avoid noisy merge commits on every sync.
• Tag releases (git tag -a v1.2.0 -m "...") so CI/CD and rollbacks have stable anchors.
• Learn the reflog — it's your safety net; almost nothing is unrecoverable.

---

Common mistakes to avoid

• Committing straight to main. Work on branches; keep main reviewable and deployable.
• Rebasing shared/pushed history. It rewrites hashes and breaks everyone who pulled. Rebase only local, un-pushed commits.
• git reset --hard as a reflex. It discards uncommitted work permanently. Prefer restore/stash, and remember reflog.
• Committing secrets. Deleting them in a later commit doesn't remove them from history. Scan, and rotate anything leaked.
• Giant, mixed commits. "Fixed stuff" across ten files can't be reviewed or reverted cleanly. One concern per commit.
• pull blind into local changes. Fetch and look first when unsure; a surprise merge/conflict mid-work is avoidable.
• Ignoring .gitignore until it's too late. Add it before the first commit so build output and deps never enter history.

---

Practice: try it yourself

1. The core loop. Init a repo, make three commits editing a file, and read git log --oneline. Stage only part of your changes with git add -p and commit them separately.
2. Branch, diverge, merge. Create a branch, commit on it, commit something else on main, then merge. Did you get a fast-forward or a merge commit? Why?
3. Undo drills. Practice each: unstage a file, discard an edit, --amend the last commit, and git revert a commit. Then "lose" a commit with reset --hard and recover it via git reflog.
4. Clean a branch for review. Make three messy commits, then git rebase -i main to squash them into one well-written commit.

Self-check:

• Name the three trees and the command that moves changes into each.
• When is it safe to rebase, and when is it dangerous?
• revert vs reset — which for shared history, which for local, and why?
• You think you deleted a commit. What's the first command you reach for?

---

Where to go next

• Automate on top of Git with the GitHub Actions tutorial — CI/CD triggered by the events you now understand.
• Adopt GitOps with the Argo CD tutorial, where a git revert is your production rollback.
• Handy tools: decode any command with the Git Command Explainer, and scaffold ignore rules with the .gitignore Generator.
• Practice with DevOps interview questions in the question bank.

You now have the full loop: stage → commit → branch → integrate → undo → collaborate. Everything else in modern DevOps assumes it.