linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
Intro
Lessons
Footer
linuxlab-TutorialsPricingAboutPrivacy & cookies
Copyright © 2026 LinuxLab. All rights reserved.
linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
  • Introduction
  • Chapters
  • How it works
  • Lessons
  • Knowledge base
  • Interview prep
home/git/how/object-model

how/objects

Object model: blob → tree → commit

Inside, Git is four object types and one big hash table. Let's see how a file on disk turns into a commit with a SHA, and why the whole history is cryptographically linked.

If you strip every command out of Git and keep a single idea, what remains is this: the object database. The .git/objects/ folder, where Git stores four object types:

  • blob is the content of one file. Just bytes.
  • tree is a listing of what sits in a directory: (permissions, type, SHA, name).
  • commit is a snapshot of a tree plus metadata (author, time, parents, message).
  • tag is a named reference to a commit (optionally signed).

Each object is addressed by its [[sha1|SHA]], a hash of its own content. Identical files get the same SHA and are stored once. History is a chain of commits where each one references its parent.

Press ▶ to follow how three files turn into one commit in four steps.

step 1/5·00 · three files sit on disk
WORKING TREEфайлы на дискеBLOBS.git/objects/TREEsnapshot директорииCOMMITSистор. цепочкаREADME.mdtext · файл на дискеindex.htmltext · файл на дискеstyle.csstext · файл на дискеblob5f7e9c1blob8a3f2e9blobb1d4a7etree · d4e5f6amode type sha name100644blob5f7e9c1README.md100644blob8a3f2e9index.html100644blobb1d4a7estyle.cssтри файла в рабочей копии · Git их ещё не видел

§ steps

  1. A project folder with three files in it: README.md, index.html, style.css. From Git's point of view this is the working copy (working-tree), just the content of the file system that you edit code in.

    Git has not seen them yet. There is nothing of ours in .git/objects/, and the index is empty. To commit anything, the files first have to be turned into objects.

recap

What to remember:

  • In Git you have snapshots, not diffs. Every commit is a full snapshot of the project through a tree. A diff is computed on the fly between two trees.
  • A SHA is both an address and an integrity check. The hash is computed from the content. Change the content and the SHA changes, and the history further down the chain finds out about it.
  • The file name lives in the tree, not in the blob. One blob can be referenced by two different names, and it is stored once.
  • A branch is just a file with a SHA inside. .git/refs/heads/main is an ordinary text file; it holds the 40-character SHA of a commit. Moving a branch means rewriting this file.
  • A commit references its parent. History is a directed acyclic graph (DAG): an ordinary commit has one parent, a merge commit has two, three, or four, and a root commit has none.

The plumbing commands (hash-object, write-tree, commit-tree, cat-file) do exactly these steps, one at a time. The high-level git commit glues them into a single operation.

§ dig into the knowledge base

  • blobblob - file content, without a name or permissions
  • treetree - a list of directory entries
  • commitcommit - a snapshot and metadata
  • sha1SHA-1 in Git - what gets hashed and how
  • branchbranch - just a file with a SHA
  • packfilepackfile - how Git packs objects on disk
Footer
linuxlab-
Copyright © 2026 LinuxLab. All rights reserved.
Tutorials
Pricing
About
Privacy & cookies