Question 1

How does Git actually store your files?

Accepted Answer

As **complete snapshots**, not as differences — which is the single fact that makes Git's behaviour comprehensible, because almost every mental model imported from older version control systems is wrong here.

**The four object types**, all stored in a content-addressed database and named by the SHA hash of their contents:

**Blob** — the contents of a file. No name, no path, just bytes.

**Tree** — a directory listing, mapping names to blobs and other trees. This is where filenames live.

**Commit** — a pointer to one tree (the full project state), plus author, message, timestamp, and pointers to **parent commits**.

**Tag** — an annotated pointer to an object.

**Why content addressing matters.** An object's name is the hash of its content, so **identical content is stored once** no matter how many commits or branches contain it. A commit that changes one file in a thousand creates one new blob, a handful of new trees along that path, and one commit object — everything else is reused by reference. This is why snapshots are not wasteful.

**It also makes history tamper-evident.** A commit's hash covers its tree and its parents, so changing anything historical changes every subsequent hash — which is exactly why rewriting published history is disruptive.

**What a branch actually is.** A **file containing a commit hash**. That is all. Creating a branch writes 41 bytes, which is why branching is instant and cheap, and why "where did my branch go" is usually a question about a moved pointer rather than lost data.

**What HEAD is** — a pointer to the current branch, or directly to a commit, which is the **detached** state.

**Where packing comes in.** Loose objects are eventually compressed into packfiles, and *there* Git does store deltas between similar objects — as a storage optimisation, invisible to the model.

**What follows practically:** commits are immutable, so rebase and amend create **new** commits; nothing reachable is deleted immediately; and **the reflog records where your branches have pointed**, which is how almost any apparently lost work is recovered.

Question 2

What does git stash do and when should I use it?

Accepted Answer

Stashing takes your uncommitted changes, saves them aside, and returns the working tree to a clean state matching the last commit. The changes are not lost; they are stored on a stack you can reapply

Question 3

What is a build artifact, and why does reproducibility matter?

Accepted Answer

An artifact is the packaged output of a build — a compiled binary, a container image, a library archive — and reproducibility means that building the same source produces an identical artifact, every

Question 4

When should I use git rebase instead of git merge?

Accepted Answer

Both commands integrate work from one branch into another, and they differ in what happens to history. Merge records that two lines of development came together, creating a merge commit with two

Question 5

How do I remove a file containing secrets from Git history?

Accepted Answer

Start with the part people skip: if a credential was pushed anywhere others could read it, treat it as compromised and rotate it first. Rewriting history removes the file from the repository, but it

Question 6

What is the difference between git fetch and git pull?

Accepted Answer

Fetching downloads new commits from the remote and updates your remote-tracking references. It changes nothing about your working tree or your local branches. After fetching you know what has

Question 7

What is a merge conflict and how do I resolve it?

Accepted Answer

A conflict occurs when two branches changed the same region of a file and Git cannot determine which version is correct. It is not an error, and it does not mean anyone did anything wrong. Git

Related Questions