Version Control with Git
Git is a distributed version control system: every clone carries the full history, not a thin copy of a central server. That is both its power and its main source of confusion. Working with Git means working with three areas (working tree, index, history) and a set of pointers (HEAD, branches, tags) that move across the commit graph. Almost every "magic" beginner error is a wrong mental model of where those pointers currently are.
The idea Git separates from "I saved the file": a commit records a snapshot of the index (the staging area), not the current on-disk content of a file. Between "I edited the file" and "the change is in the commit" sits an explicit git add step. A branch is not "a copy of the project" — it is a movable pointer to a commit. HEAD is the pointer to where you currently stand. Understanding these pointers turns scary situations (detached HEAD, merge conflict, a "lost" commit) into predictable ones. The full map lives in the layers below.
Topic map
- Git basics and the three areas — the distributed model, working tree / index / history,
HEAD, the everyday commands. - The index and commits — what
git adddoes, why a commit records a snapshot of the index,-aand its new-file trap. - Inspecting history —
git log,git show,git diff,git blame; reading the commit graph. - Branching — a branch as a pointer,
HEAD, detached HEAD and how to leave it without losing work. - Merging and conflicts — fast-forward vs merge commit, how a conflict arises and how to resolve it.
- Syncing with remotes —
fetchvspullvspush, tracking branches, whypullisfetch+merge. - Stashing — how to shelve uncommitted work, the stash stack, what does NOT go into a stash by default.
Common traps
| Mistake | Consequence |
|---|---|
| Assuming a commit takes the current on-disk file | A commit records a snapshot of the index; edits made after git add are not included until you add again |
git commit -a for a new file | -a stages only already-tracked files; a new (untracked) file is not committed |
Committing with <<<<<<< markers left in | An unresolved conflict lands in history — the code will not build |
| Working and committing in a detached HEAD | Commits are not attached to a branch; switch away and they "vanish" (reachable only via reflog) |
Treating git pull as a safe "update" | pull = fetch + merge; it can create an unexpected merge commit or a conflict |
Deleting a branch with unmerged work (git branch -D) | The branch's commits survive only in reflog and will be garbage-collected |
Thinking git stash saves everything | Untracked and ignored files do NOT go into a stash by default |
Confusing git checkout -- file with "undo" | The command discards uncommitted working-tree edits irreversibly |
Interview relevance
Git comes up on almost every engineering interview — but the check is your model of repository state, not command recall. A candidate who explains git commit as "records a snapshot of the index that the branch then points to" immediately stands out from "well, it saves changes".
Typical checks:
- The three areas — working tree, index (staging), history — and how
add/commitmove data between them. - A branch = a pointer to a commit; what
HEADand a detached HEAD are. - The difference between
git fetchandgit pull(and whypullcan surprise you with a merge commit). - How a merge conflict arises and the sequence to resolve it.
- What
git stashdoes and what it leaves behind. - Fast-forward vs merge commit.
Common wrong answer: "git pull just downloads the latest version". That opens the discussion that pull merges the remote branch into your local one, so it can create a merge commit or a conflict — and that git fetch plus a deliberate merge/rebase is often preferable.