Git Version Control Quiz.

The Necessity of Deep Git Knowledge

In modern software development, writing code is only half the battle. Managing its evolution, collaborating with distributed teams, and untangling merge conflicts without losing work is arguably just as critical. Despite the proliferation of visual UI GUI clients (Tower, Fork, GitKraken), mastering the underlying Git CLI remains a non-negotiable prerequisite for any senior engineer in 2026.

A software developer who only knows the holy trinity of git pull, git commit, and git push is a ticking time bomb. They are a liability when an inevitable conflict occurs or when history needs to be surgically altered to remove an accidentally committed API key. A developer who understands the Directed Acyclic Graph (DAG) structure behind Git can navigate any disaster scenario without fear.

Git Under the Hood: The DAG

Git does not store diffs. Traditional version control systems like Subversion (SVN) tracked files purely as a list of changes occurring over time (delta-based). Git, however, takes a snapshot of your entire filesystem at the moment of the commit. If a file hasn't changed, Git simply links to the previous identical file object to save space.

Every commit points to its parent commit, creating a Directed Acyclic Graph (DAG). A "branch" in Git is not an isolated folder—it is merely a lightweight, movable pointer (a 40-character SHA-1 checksum reference) pointing to a specific node on that graph. When you understand that branches are just sticky notes on commits, concepts like merging, detaching the HEAD pointer, and rebasing lose all of their intimidating mystique.

The Architecture of the Three Trees

Most state-management confusion arises from failing to separate Git into its three distinct local environments. You are always manipulating code between three "trees":

• The Working Directory: Your physical files on the hard drive. This is the messy sandbox where you are currently typing.
• The Staging Area (Index): The loading dock. When you run git add, you are selectively moving files from the sandbox onto the dock, preparing them for the next shipment.
• The Repository (HEAD): The permanent locker. When you run git commit, you lock the staging area into a permanent historical snapshot in the local .git database.

Commands like git reset are fundamentally about moving code backwards across these trees. A --soft reset moves HEAD but leaves the index and working directory untouched. A --mixed reset (the default) clears the index too. A --hard reset viciously synchronizes all three trees to the past, permanently obliterating uncommitted work.

Merge vs. Rebase: The Eternal War

When a feature branch diverges from the main trunk, you have two options to integrate upstream changes. The standard git merge creates a new "Merge Commit" that conceptually joins the two histories together. This preserves flawless chronological accuracy, but heavily tracked repositories quickly turn into illegible, spiderweb-like graphs full of redundant merge commits.

git rebase takes the alternative approach. It rewinds your local branch to the common ancestor, applies the new commits from the main trunk, and then elegantly replays your local feature commits on top. The result is a beautifully clean, linear history. However, rebasing destroys existing commits and creates brand-new ones. If you rebase a commit that another developer has already pulled down, you will trigger a catastrophic topological paradox in the repository. The golden rule of Git: never rebase branched history that has been pushed to a public remote.

The Reflog: Your Ultimate Safety Net

The greatest secret in Git is that it is incredibly difficult to truly delete a committed file. Even if you perform a disastrous git reset --hard and lose your branch pointer, the commit object still exists in the local database.

The Reference Logs (Reflog) silently record every single time the HEAD pointer moves. By running git reflog, you can see a chronological history of your terminal actions over the last 90 days. You can locate the lost commit’s SHA checksum and simply run git checkout <hash> to magically reconstruct your "destroyed" repository state. The Reflog is the ultimate undo button for Git emergencies.

Execution Tiers