Git & Version Control Internals

Question 1

What does a Git commit actually store?

Accepted Answer

A full snapshot of every tracked file at that point in time — Conceptually, each commit is a complete snapshot of the project. Git is smart enough to deduplicate unchanged files internally using content-addressed storage, but the logical model is "whole snapshot", not "patch". This is why switching branches is fast — Git just checks out the snapshot the target branch points to.

Question 2

What is a Git branch, at its most fundamental level?

Accepted Answer

A lightweight movable pointer to a specific commit — A branch is nothing more than a named pointer (stored as a 41-byte text file in .git/refs/heads/) that moves forward automatically whenever you make a new commit on that branch. Creating a new branch is nearly instant because Git is only writing a single tiny file, not copying any project files.

Question 3

What does HEAD refer to in Git?

Accepted Answer

A special pointer to whatever commit or branch tip you are currently on — HEAD is a special pointer that tells Git "this is where you are right now." When you check out a branch, HEAD points to that branch name, which in turn points to its latest commit. If you check out a raw commit hash (detached HEAD state), HEAD points directly to that commit instead of through a branch.

Question 4

When Git creates a merge commit, what makes it structurally different from a regular commit?

Accepted Answer

It has two (or more) parent pointers instead of one — A merge commit has exactly two parents: the previous tip of the branch you merged into, and the tip of the branch you merged in. This dual-parent structure is how Git preserves the full history of both lines of development and is what lets tools like "git log --graph" draw the familiar fork-and-rejoin shape.

Question 5

What causes a merge conflict?

Accepted Answer

The same lines in the same file were edited differently on each branch — Git can usually auto-merge changes on different lines or in different files. A conflict arises specifically when two branches each changed the same line(s) in incompatible ways and Git cannot determine which version (or what combination) you want to keep. You must resolve it manually by editing the file, removing the conflict markers, and staging the result.

Question 6

What is a fast-forward merge and when does Git use it?

Accepted Answer

A merge where main has not diverged past the branch point, so Git moves its pointer forward without creating a new commit — If main has not moved since you branched off, your feature branch is simply ahead of main in a straight line. Git can "fast-forward" the main pointer to the tip of feature without creating a merge commit — because there is no divergence to reconcile. Use "git merge --no-ff" to force a merge commit even in this case if you want the explicit history.

Question 7

Why is creating a feature branch a better practice than committing directly to main?

Accepted Answer

It isolates in-progress work so main stays deployable; you merge only when the feature is ready — A feature branch gives you an isolated workspace. Main (or whatever your production branch is) stays stable and deployable while you experiment, break things, and iterate on the branch. Other team members can keep pulling from main without being affected by your work-in-progress. Code review happens on the branch before it is merged.

Question 8

What is the key conceptual difference between "git merge" and "git rebase"?

Accepted Answer

git merge creates a two-parent commit preserving both timelines; git rebase replays commits onto the target producing a linear history with new SHAs — "git merge" integrates changes by creating a new merge commit with two parents, preserving the exact history of when and where branches diverged. "git rebase" picks up your commits and replays them as new commits on top of the target branch, rewriting commit hashes to produce a clean linear history. Rebase is tidy but rewrites history — avoid rebasing commits already pushed to a shared branch.

Question 9

Which command would you run to see a graph of commits and branch pointers in your terminal?

Accepted Answer

git log --oneline --graph --all — "git log --oneline --graph --all" prints a compact ASCII art tree of every commit and branch in the repository, which matches the mental model in this visualization. The "--all" flag includes all branches, not just the one you're currently on.

Question 10

After resolving a merge conflict, what must you do before Git can complete the merge?

Accepted Answer

Stage the resolved files with git add, then run git commit or git merge --continue to finalize the merge commit — Git pauses mid-merge when it hits conflicts. After you manually edit the conflicted files and remove the conflict markers (<<<<<<<, =======, >>>>>>>), you must stage those files with "git add" to signal that the conflict is resolved. Git then lets you create the merge commit with "git commit" (or "git merge --continue" in newer Git versions).

Commit Graph

Blob, tree or commit?

Test your knowledge

What does a Git commit actually store?

The short version

Interview Questions

References & Further Reading

Related topics

Love this visualization?