Git becomes much easier to use when you stop thinking about it as a folder full of version numbers and start thinking about it as a content-addressed object database. Commits, trees, and blobs describe project state, while refs such as branches and tags give humans convenient names for important commits.
Blobs store file content
A blob is Git's basic object for file contents. It does not need to know whether the file is called app.tsx or README.md; the directory structure lives in tree objects. Content is addressed by a hash, which lets Git identify identical objects efficiently.
Trees describe directories
A tree records entries such as filenames, modes, and the object IDs they point to. A repository snapshot is therefore assembled from trees and blobs rather than duplicated as a complete folder for every commit.
Commits connect snapshots
A commit points to a root tree and includes metadata such as the author, committer, message, and parent commit(s). A normal commit has one parent; a merge commit can have multiple parents.
Branches are names, not copies
A branch is essentially a movable reference to a commit. Creating a branch does not copy every file. It creates a lightweight name pointing at a commit, and a new commit moves the branch reference forward.
HEAD explains “where am I?”
HEAD identifies the currently checked-out reference or commit. When you switch branches, Git updates the working tree to match that branch. A detached HEAD simply means HEAD points directly to a commit rather than to a branch name.
Useful plumbing commands
git cat-file -p HEAD
git rev-parse HEAD
git ls-tree HEAD
git log --oneline --graph --decorate --allThese commands are useful because they expose the structures behind familiar porcelain commands. Once you understand them, operations like reset, revert, rebase, and merge become easier to reason about.
Reset vs revert
Reset moves a reference and can change the visible history of a branch. Revert creates a new commit that reverses an earlier change. The distinction matters when working with shared branches because public history usually should not be rewritten casually.
Why this design is powerful
Git's object model makes branching cheap, enables deduplication, and provides a strong relationship between history and content. You can inspect exactly which tree a commit points to and which objects make up that tree.
For a broader software engineering workflow, explore ourDevOps & Git courseand the deployment foundations in ourcontainers guide.