از چند فایل تا یک commitFrom files to a commit

یک پوشهٔ کوچک را تصور کن: دو فایل و یک زیرپوشه. Git باید هم محتوای فایل‌ها را نگه دارد، هم اسم و جای آن‌ها را، و هم بداند این عکس فوری بعد از کدام commit آمده. به‌جای حفظ جواب، مسیر را از بایت‌های فایل تا commit با دست دنبال می‌کنیم.

Imagine a folder with two files and one subdirectory. Git must retain file bytes, know their names and locations, and record which snapshot came before. If you think it creates one giant project file, we'll test that idea in a moment.

مسیر اصلی: بایت‌های فایل به blob، فهرست پوشه به tree، و tree ریشه همراه با والد و اطلاعات نویسنده، ثبت‌کننده و پیام به commit می‌رسد. اسم انسانی مثل شاخه یا tag هم اشاره‌گری است که به شیء اشاره می‌کند؛ خودش عکس فوری نیست.

The path is: file bytes become a blob; a directory listing becomes a tree; and the root tree plus parent, author, committer, and message form a commit. A human name such as a branch or tag is a ref to an object, not the snapshot itself.

blob: محتوا بدون اسم فایلA blob: content without a filename

آیا مسیر فایل در شناسه‌اش دخیل است؟ hash-object می‌تواند شناسه را حساب کند؛ با -w همان شیء را هم در مخزن می‌نویسد. اول فقط حسابش کنیم.

Does a file path contribute to its ID? hash-object computes an ID; -w also writes the object. First, compute only:

printf 'hello\n' | git hash-object --stdin
ce013625030ba8dba906f756967f9e9ca394464a

این شناسه یک blob برای همین شش بایت در مخزن SHA-1 است؛ بدون -w چیزی ذخیره نشده. Git فقط متن خام را hash نمی‌کند: سرآیند مفهومی blob 6\0 می‌آید—نوع، فاصله، اندازه برحسب بایت، NUL و بعد محتوا. برای شیءهای دیگر هم نوع و محتوای serialized آن‌ها دخیل است.

This is the blob ID for these six bytes in a SHA-1 repository; without -w, nothing is stored. Git does not hash raw text alone: a conceptual header blob 6\0 comes first—type, space, byte size, NUL, then content. Other object types include their type and serialized content too.

یک بایت را عوض کنیم. قبل از اجرا حدس بزن: آیا شناسه همان می‌ماند؟ هر دو فرمان فقط حساب می‌کنند و چیزی ذخیره نمی‌کنند.

Change one byte. Predict first: will the ID stay the same? Both commands only compute; neither stores an object.

printf 'hello\n' | git hash-object --stdin
ce013625030ba8dba906f756967f9e9ca394464a
printf 'hellO\n' | git hash-object --stdin
a different object ID

شناسه عوض شد، چون بایت محتوا عوض شده است. این مشاهده را به تضمین ریاضیِ «برخورد ناممکن است» تبدیل نکن؛ برای کاربرد معمول، Git به hash مقاوم به برخورد تکیه می‌کند.

The ID changes because the content bytes changed. Do not turn this observation into a mathematical claim that collisions are impossible; Git relies on a collision-resistant hash for practical use.

حالا در یک مخزن آزمایشی شیء را بنویس و نوع و اندازه‌اش را بپرس:

Now write the object in a disposable repository and inspect its type and size:

git init -q object-lab
cd object-lab
blob=$(printf 'hello\n' | git hash-object -w --stdin)
git cat-file -t "$blob"
blob
git cat-file -s "$blob"
6
printf '%s\n' "$blob"
ce013625030ba8dba906f756967f9e9ca394464a
printf '.git/objects/%s/%s\n' "$(printf '%s' "$blob" | cut -c1-2)" "$(printf '%s' "$blob" | cut -c3-)"
.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a
git cat-file -p "$blob"
hello

-t نوع را نشان می‌دهد، -s اندازهٔ محتوا را و -p نمایش خوانا را. دو حرف اول شناسه پوشه و باقی‌اش نام فایل جدا هستند. اما مسیر مستقل فقط یک شکل ذخیره‌سازی است؛ بعداً شیء ممکن است وارد pack شود. blob در هیچ‌کدام از این خروجی‌ها اسم فایل ندارد.

-t shows type, -s content size, and -p readable content. The first two ID characters name the loose-object directory; the rest name its file. But a standalone path is only one storage form; the object may later be packed. None of these blob views includes a filename.

tree اسم و مجوز و شناسه را کنار هم می‌گذاردA tree combines names, modes, and IDs

اگر blob اسم را نمی‌داند، «این محتوا در notes/today.txt است» کجا ثبت می‌شود؟ در tree. هر مدخل نام، مجوز، نوع و شناسه دارد؛ مسیر تو‌در‌تو با کنار هم گذاشتن مدخل‌های چند tree ساخته می‌شود.

If a blob does not know its name, where does Git record “this content is notes/today.txt”? In a tree. Each entry has a name, mode, type, and ID; nested paths compose entries across trees.

خروجی git ls-tree این مدخل‌ها را خوانا می‌کند. 100644 فایل معمولی، 100755 اجرایی، 120000 symlink، 040000 پوشه و 160000 gitlink یک submodule است. این مجوزها Unix-like هستند و همهٔ owner/group و مجوزهای محلی را کپی نمی‌کنند.

git ls-tree renders these entries readably. 100644 is a regular file, 100755 executable, 120000 symlink, 040000 directory, and 160000 a submodule gitlink. These Unix-like modes do not copy every local owner/group and permission bit.

محتوای یکسان را زیر دو اسم ناحیه‌ آماده‌سازی کن و شناسهها را مقایسه کن. ls-files --stage ناحیه‌ آماده‌سازی را می‌خواند؛ هنوز commit نداریم.

Stage identical content under two names and compare IDs. ls-files --stage reads the index; there is no commit yet.

mkdir -p assets
printf 'shared note\n' > assets/one.txt
cp assets/one.txt assets/two.txt
git add assets/one.txt assets/two.txt
git ls-files --stage
100644 a1b2c3d4... 0\tassets/one.txt
100644 a1b2c3d4... 0\tassets/two.txt
git commit -m 'Add two names for one note'
git ls-tree HEAD:assets
100644 blob a1b2c3d4...    one.txt
100644 blob a1b2c3d4...    two.txt

دو مسیر به یک blob شناسه می‌رسند. اگر تغییرنام کنی، blob می‌تواند همان بماند، اما tree نام تازه‌ای دارد و شناسهٔ tree عوض می‌شود. ناحیه‌ آماده‌سازی قبل از commit فهرستی تخت از مسیرهاست؛ commit آن را به treeهای تو‌در‌تو تبدیل می‌کند.

Both paths reach one blob ID. A rename can leave the blob unchanged while changing the tree entry and tree ID. Before commit, the index is a flat path list; commit turns it into nested trees.

commit: عکس فوری به‌علاوهٔ تاریخچهA commit: snapshot plus history

tree شکل پوشه را می‌داند، نه اینکه چه کسی عکس فوری را نوشته یا بعد از کدام commit آمده. یک مخزن کوچک می‌سازیم، با مسیر معمول add و commit، بعد نتیجه را از پایگاه اشیا می‌خوانیم.

A tree knows the directory shape, not who authored the snapshot or which commit came before. We'll use the normal add/commit workflow, then inspect the object database.

git config user.name 'Ada Example'
git config user.email 'ada@example.test'
mkdir -p notes
printf '# Field notes\n' > README.md
printf 'first observation\n' > notes/today.txt
git add README.md notes/today.txt
git commit -m 'Record first observation'
[main (root-commit) 31a6f2c] Record first observation
 2 files changed, 2 insertions(+)
 create mode 100644 README.md
 create mode 100644 notes/today.txt
git cat-file -p HEAD
tree 8c01d4e...
author Ada Example <ada@example.test> 1750000000 +0330
committer Ada Example <ada@example.test> 1750000000 +0330

Record first observation

شناسه و زمان نمونه‌اند؛ در مخزن تو فرق می‌کنند. خط tree tree ریشه را معرفی می‌کند. commit اول والد ندارد؛ commit معمولی بعدی یک والد دارد و merge می‌تواند چند والد داشته باشد. نویسنده تغییر را نوشته؛ ثبت‌کننده آن را در این commit ثبت کرده، پس این دو می‌توانند متفاوت باشند.

The sample ID and timestamp are illustrative. The tree line names the root tree. The initial commit has no parent; an ordinary later commit has one and a merge may have several. The author wrote the change; the committer recorded it, so they can differ.

فقط یادداشت را عوض می‌کنیم و عکس فوری دوم را می‌سازیم:

Change only the note and create a second snapshot:

printf 'second observation\n' > notes/today.txt
git add notes/today.txt
git commit -m 'Record second observation'
git cat-file -p HEAD
tree 9a7b3c1...
parent 31a6f2c...
author Ada Example <ada@example.test> ...
committer Ada Example <ada@example.test> ...

Record second observation
git ls-tree HEAD
100644 blob 7d8e9f0...    README.md
040000 tree 4a5b6c7...    notes
git ls-tree HEAD:notes
100644 blob 2f3a4b5...    today.txt

از HEAD به tree ریشه و بعد به پوشه رسیدیم. blob فایل تغییرکرده شناسه تازه دارد؛ treeهای مسیر هم عوض‌اند. blob README که عوض نشده می‌تواند در هر دو عکس فوری همان شناسه را داشته باشد.

We followed HEAD to the root and nested tree. The changed file's blob gets a new ID, as do trees along its path. Unchanged README can reuse its ID in both snapshots.

پیام یکسان یعنی commit یکسان نیست. tree، والدها، نویسنده، ثبت‌کننده، زمان و پیام در محتوای commit هستند و روی شناسه اثر می‌گذارند. مدل منطقی Git عکس فوری است و diff از مقایسهٔ عکس فوریها ساخته می‌شود؛ این به معنی مدل‌کردن تاریخچه به شکل diff نیست.

Same message does not mean same commit. Tree, parents, author, committer, timestamps, and message contribute to the ID. Git's logical model is snapshots; a diff is computed by comparing snapshots, not used as the history model.

tag سبک و نشانه‌دارLightweight and annotated tags

tag همیشه اشاره‌گری با نام انسانی است؛ اما اشاره‌گر سبک مستقیم به شیء هدف می‌رسد، معمولاً commit. tag نشانه‌دار یک شیء جدا از نوع tag می‌سازد که پیام، زمان و tagger را نگه می‌دارد و خودش به هدف اشاره می‌کند.

A tag is a human-named ref, but a lightweight ref points directly to its target, usually a commit. An annotated tag creates a separate tag object with message, date, and tagger, which points to the target.

git tag v1-light
git tag -a v1-release -m 'First inspected release'
git show-ref --tags
9c8d7e6... refs/tags/v1-light
6d7e8f9... refs/tags/v1-release
git cat-file -t refs/tags/v1-light
commit
tag_oid=$(git show-ref --hash refs/tags/v1-release)
git cat-file -t "$tag_oid"
tag
git cat-file -p "$tag_oid"
object 9c8d7e6...
type commit
tag v1-release
tagger Ada Example <ada@example.test> ...

First inspected release

در نمونه، اشاره‌گر سبک مستقیم به commit می‌رسد؛ اشاره‌گر نشانه‌دار به tag object. اینجا فقط ساختار را می‌خوانیم؛ گردش‌کار روزمرهٔ tag در فصل ۱۱ می‌آید.

Here the lightweight ref points directly to a commit; the annotated ref points to a tag object. We are only inspecting structure; Chapter 11 covers day-to-day tag workflows.

شیء را با فایل فیزیکی‌اش یکی ندانDo not confuse an object with its physical file

شیء تازه معمولاً اول به‌شکل جدا در .git/objects نوشته می‌شود. Git می‌تواند بعداً آن‌ها را در packfile جمع کند و از delta compression برای صرفه‌جویی استفاده کند. این شکل فیزیکی ذخیره‌سازی است؛ مدل منطقی هنوز شیءهای blob/tree/commit با شناسههای خودشان است.

New objects are commonly written loose under .git/objects. Git can later consolidate them into packfiles and use delta compression to save space. That is physical storage; the logical model remains blobs, trees, and commits with their own IDs.

git count-objects -vH
count: 12
size: 48.00 KiB
in-pack: 0
packs: 0
size-pack: 0 bytes
# پس از maintenance، بخشی از خروجی ممکن است چنین شود:
git count-objects -vH
count: 0
size: 0 bytes
in-pack: 12
packs: 1
size-pack: 3.20 KiB

اعداد نمونه‌اند. count/size دربارهٔ جداهاست و in-pack/size-pack دربارهٔ packها. اگر فایل شیء را در مسیر قبلی پیدا نکردی، اول git cat-file را امتحان کن؛ ممکن است شیء بسته‌بندی‌شده باشد. نبود فایل مستقل در مسیر جدا به معنی نبود شیء نیست.

The numbers are illustrative. count/size describe loose objects; in-pack/size-pack describe packs. If the old path is absent, try git cat-file first—the object may be packed. No standalone loose file does not mean no object.

از خطا به سؤال تشخیصیTurn an error into a diagnostic question

اگر چیزی با مدل ذهنی‌ات جور درنمی‌آید، مخزن را دست‌کاری نکن. اول سؤال را کوچک کن: این شناسه واقعاً وجود دارد؟ نوعش چیست؟ از کدام tree به آن می‌رسیم؟ بیشتر خطاهای این بخش وقتی روشن می‌شوند که دوباره زنجیرهٔ «commit → tree → blob» را آرام و مرحله‌به‌مرحله دنبال کنی.

If Git rejects a short ID or a filename is absent from a blob, do not randomly change the repository. Narrow the question: does the ID exist? Is it unique? What type is it? Which tree points to it?

اگر cat-file شیء را پیدا نکند، فقط می‌دانیم در پایگاه اشیای در دسترس این مخزن با ورودی داده‌شده پیدا نشده؛ شناسه شاید ناقص باشد، شیء در مخزن دیگری باشد یا هرگز ذخیره نشده باشد. بدون شاهدی از نسخهٔ ذخیره‌شده، قول بازیابی نده.

If cat-file cannot find it, we only know it was not found with this input in stores available to this repository. The ID may be incomplete, the object may live elsewhere, or it may never have been stored. Do not promise recovery without evidence of a stored copy.

تمرین‌هاExercises

اینجا قرار نیست اسم blob و tree را از حفظ پس بدهی. هر تمرین یک سرنخ می‌دهد و ازت می‌خواهد از روی همان سرنخ بفهمی Git چه چیزی ذخیره کرده. قبل از اجرای دستور جواب خودت را حدس بزن؛ بعد خروجی را مثل مدرک بخوان، نه مثل عددی که فقط باید با پاسخ ما یکی باشد.

Eighteen exercises, from reading one object to tracing several layers. Try each first; later exercises combine multiple clues.

oid=$(printf 'note\n' | git hash-object -w --stdin)
git cat-file -t "$oid"
blob

printf 'hello\n' | git hash-object --stdin
printf 'hellO\n' | git hash-object --stdin

git cat-file -p <commit-id>
git ls-tree <commit-id>
git ls-tree <commit-id>:notes
git cat-file -p <blob-id>

پروژهٔ کوچک: کارآگاه شیءهاMini project: object detective

mkdir object-detective
cd object-detective
git init -q
git config user.name 'Ada Example'
git config user.email 'ada@example.test'
mkdir -p reports/assets
printf '# Project\n' > README.md
printf 'The launch moved to Thursday.\n' > reports/brief.txt
printf 'logo-v1\n' > reports/assets/mark.txt
git add README.md reports
git commit -m 'Add project report'
printf 'The launch moved to Friday.\n' > reports/brief.txt
git add reports/brief.txt
git commit -m 'Update launch date'
printf 'Uncommitted note\n' > reports/brief.txt

git rev-parse HEAD
git cat-file -t HEAD
git cat-file -p HEAD
git ls-tree HEAD
git ls-tree HEAD:reports
git ls-tree HEAD:reports/assets
git cat-file -p <brief-blob-id>
git log --oneline
git ls-tree <older-commit>
git ls-tree <newer-commit>

نقشهٔ سریع شیءهاQuick object map

این بخش برای مرور سریع است، نه جایگزین داستان فصل. اگر چیزی یادت رفت، به جای حفظ دستورها فقط زنجیره را به خاطر بیاور: محتوا در blob، اسم و مسیر در tree، و تاریخچه و والدها در commit.

Now we know what Git stores. Chapter 03 asks the next question: before a commit exists, where exactly are our changes?