دردی که Git درمان می‌کندThe pain Git treats

قبل از اینکه یک دستور بزنیم، بیایید ببینیم بدون Git چه می‌کردیم. چون هر قابلیت Git جواب یک درد مشخص است، و اگر آن درد را حس نکرده باشی، آن قابلیت برایت فقط یک دستور عجیب دیگر است.

Before typing a command, let us look at what we did without Git. Every Git feature answers a specific pain, and if you have not felt the pain, the feature is just another strange command.

این پوشه را احتمالاً دیده‌ای — شاید روی دسکتاپ خودت:

You have probably seen this folder — perhaps on your own desktop:

project/
project-backup/
project-backup2/
project-final/
project-final-REAL/
project-final-REAL-fixed/
project_ارسالی_مشتری/
project_ارسالی_مشتری_ویرایش۳/

این یک شوخی نیست؛ یک سیستم کنترل نسخه است. فقط سیستم بدی است. بیایید دقیق بگوییم چرا بد است، چون هر کدام از این ایرادها بعداً به یک قابلیت Git تبدیل می‌شود.

This is not a joke; it is a version control system. It is simply a bad one. Let us say precisely why it is bad, because each of these flaws later becomes a Git feature.

1. نمی‌دانی چه چیزی عوض شده You cannot see what changed

   بین project-final و project-final-REAL چه فرقی هست؟ باید فایل‌به‌فایل باز کنی و چشمی مقایسه کنی. اگر پروژه هزار فایل داشته باشد، عملاً غیرممکن است. Git جواب این را diff می‌نامد.

   What differs between project-final and project-final-REAL? You must open them file by file and compare by eye. With a thousand files it is effectively impossible. Git calls the answer to this diff.

2. نمی‌دانی چرا عوض شده You cannot see why it changed

   فرض کن فهمیدی خط ۴۲ عوض شده. چرا؟ سه ماه پیش خودت عوضش کردی و دلیلش را فراموش کرده‌ای. نام پوشه جای توضیح نیست. Git جواب این را پیام commit می‌نامد.

   Say you work out that line 42 changed. Why? You changed it three months ago and have forgotten the reason. A folder name is not a place for an explanation. Git calls the answer to this the commit message.

3. نمی‌توانی مطمئن باشی چیزی گم نشده You cannot be sure nothing was lost

   کپی‌کردن پوشه ممکن است نصفه بماند، یک فایل جا بیفتد، یا فایلی خراب کپی شود و هیچ‌کس تا شش ماه بعد نفهمد. Git جواب این را آدرس‌دهی بر اساس محتوا می‌نامد — که کل بخش سوم همین فصل است.

   Copying a folder can stop halfway, miss a file, or corrupt one, and nobody notices for six months. Git calls the answer to this content addressing — the subject of section three.

4. دو نفر نمی‌توانند همزمان کار کنند Two people cannot work at once

   اگر تو و همکارت هر دو روی یک فایل کار کنید، یکی‌تان کار دیگری را پاک می‌کند. راه‌حل سنتی این بود که فایل را «قفل» کنی تا کسی دیگر بازش نکند — یعنی همکارت باید منتظر بماند. Git جواب این را merge می‌نامد.

   If you and a colleague both edit one file, one of you erases the other's work. The traditional fix was to “lock” the file so nobody else could open it — meaning your colleague waits. Git calls the answer to this merge.

Git از کجا آمدWhere Git came from

این بخش تاریخ برای حفظ کردن نیست. Git چند تصمیم عجیب دارد که فقط وقتی معنا می‌دهند که بدانی در چه شرایطی و برای چه کسی ساخته شد.

This section is not history to memorise. Git makes a few odd decisions that only make sense once you know the circumstances it was built under, and for whom.

کنترل نسخه از دههٔ ۱۹۷۰ وجود داشت. نسل اول — مثل RCS — فقط یک فایل را روی یک ماشین دنبال می‌کرد. نسل دوم — CVS و بعد Subversion — یک سرور مرکزی داشت که همهٔ تاریخچه آنجا بود و هر کسی برای هر کاری باید به آن وصل می‌شد. این یعنی بدون شبکه نمی‌توانستی commit بزنی، و اگر سرور می‌مرد، تاریخچهٔ همه با آن می‌مرد.

Version control existed from the 1970s. The first generation — RCS — tracked one file on one machine. The second — CVS, then Subversion — had a central server holding all history, which everyone had to reach for everything. That meant no committing without a network, and if the server died, everyone's history died with it.

در سال ۲۰۰۵، هستهٔ لینوکس از یک ابزار تجاری به نام BitKeeper استفاده می‌کرد و دسترسی رایگانش قطع شد. مسئله این بود: هزاران توسعه‌دهنده در سراسر دنیا، بدون هماهنگی مرکزی، روی پروژه‌ای با میلیون‌ها خط کد. لینوس توروالدز در چند هفته ابزار تازه‌ای نوشت با سه الزام صریح:

In 2005 the Linux kernel was using a commercial tool called BitKeeper, and its free access was withdrawn. The problem was this: thousands of developers worldwide, with no central coordination, on a project of millions of lines. Linus Torvalds wrote a new tool in a few weeks with three explicit requirements:

آن الزام سوم مهم‌ترین است، چون چیزی که برای امنیت طراحی شد، به‌طور اتفاقی کل مدل ذهنی Git را ساخت. بخش بعد دقیقاً همین است.

The third requirement matters most, because something designed for security accidentally produced Git's entire mental model. That is exactly what the next section is about.

Git واقعاً چه چیزی ذخیره می‌کندWhat Git actually stores

این مهم‌ترین بخش کل مسیر است. اگر فقط یک بخش از این فصل را بخوانی، همین باشد.

This is the most important section in the whole track. If you read only one section, read this one.

تصور رایج این است که Git «تغییرات» را ذخیره می‌کند — یعنی برای هر commit می‌نویسد «در خط ۴۲ این کلمه به آن کلمه تبدیل شد». این تصور غلط است، و تقریباً همهٔ سردرگمی‌های بعدی از همین می‌آید.

The common assumption is that Git stores “changes” — that each commit records “on line 42, this word became that word”. That assumption is wrong, and nearly all later confusion follows from it.

Git یک پایگاه‌دادهٔ کلید-مقدار است. تو محتوایی به آن می‌دهی، و آن یک کلید به تو پس می‌دهد. کلید، خلاصهٔ رمزنگاری‌شدهٔ خودِ محتوا است. بیایید ثابتش کنیم — این را روی سیستم خودت اجرا کن:

Git is a key-value store. You hand it content and it hands you back a key. That key is a cryptographic digest of the content itself. Let us prove it — run this on your own machine:

# محتوای «hello» را به Git بده و بپرس کلیدش چه می‌شود.
# ‏--stdin یعنی محتوا را از ورودی می‌گیرم، نه از یک فایل.
printf 'hello\n' | git hash-object --stdin
ce013625030ba8dba906f756967f9e9ca394464a

این خاصیت اسم دارد: آدرس‌دهی بر اساس محتوا (content-addressable storage). و سه نتیجهٔ فوری دارد که ارزش دارد رویشان مکث کنی:

This property has a name: content-addressable storage. It has three immediate consequences worth pausing on:

• محتوای یکسان، کلید یکسان. اگر همان فایل در ده پوشه تکرار شده باشد، Git فقط یک بار ذخیره‌اش می‌کند.
• Identical content, identical key. If the same file appears in ten folders, Git stores it once.
• خرابی قابل تشخیص است. اگر یک بایت از یک فایل ذخیره‌شده خراب شود، کلیدش دیگر با محتوایش نمی‌خواند و Git فوراً می‌فهمد.
• Corruption is detectable. If one byte of a stored file rots, its key no longer matches its content and Git knows immediately.
• تاریخچه غیرقابل جعل است. چون کلید هر commit شامل کلید commit قبلی است، عوض کردن یک commit قدیمی یعنی عوض شدن کلید همهٔ commitهای بعدی. این دقیقاً همان چیزی است که در فصل ۷ به آن می‌گوییم «قانون طلایی rebase».
• History cannot be forged. Because each commit's key includes the previous commit's key, altering an old commit changes the key of every commit after it. That is precisely what chapter 7 calls “the golden rule of rebase”.

چهار نوع شیء

The four object types

داخل این پایگاه‌داده فقط چهار نوع چیز وجود دارد. همه‌چیز — کل Git — از همین چهارتا ساخته شده.

Inside this database there are only four kinds of thing. Everything — all of Git — is built from them.

یک نتیجهٔ مهم از این نمودار: هر commit یک عکس کامل از کل پروژه است، نه فهرستی از تغییرات. پس چرا مخزن‌ها این‌قدر کوچک‌اند؟ چون اگر فایلی بین دو commit عوض نشده باشد، محتوایش یکسان است، پس کلیدش یکسان است، پس هر دو tree به همان یک blob اشاره می‌کنند. تکراری ذخیره نمی‌شود. صرفه‌جویی خودبه‌خود از مدل داده می‌آید، نه از یک الگوریتم فشرده‌سازی هوشمند.

An important consequence of that diagram: every commit is a complete snapshot of the whole project, not a list of changes. So why are repositories so small? Because if a file did not change between two commits, its content is identical, so its key is identical, so both trees point at the same single blob. Nothing is stored twice. The saving falls out of the data model rather than from a clever compression algorithm.

و diff؟ Git آن را در لحظه محاسبه می‌کند با مقایسهٔ دو عکس. ذخیره‌اش نمی‌کند. این دقیقاً برعکس چیزی است که بیشتر آدم‌ها فکر می‌کنند.

And the diff? Git computes it on the spot by comparing two snapshots. It never stores it. This is precisely the opposite of what most people assume.

سه ناحیهThe three areas

حالا که می‌دانیم Git چه چیزی ذخیره می‌کند، سؤال بعدی این است: کِی ذخیره‌اش می‌کند. جوابش سه ناحیه است — و ناحیهٔ وسط همان چیزی است که تازه‌کارها را گیج می‌کند.

Now that we know what Git stores, the next question is when it stores it. The answer is three areas — and the middle one is what confuses newcomers.

چرا ناحیهٔ وسط اصلاً وجود دارد؟

Why does the middle area exist at all?

این سؤالی است که تقریباً همه می‌پرسند: چرا نمی‌شود مستقیم commit زد؟ چرا باید اول add کنم؟

Nearly everyone asks this: why can I not commit directly? Why must I add first?

جوابش این است: ناحیهٔ آماده‌سازی به تو اجازه می‌دهد commit را طراحی کنی، نه فقط ثبتش کنی. یک موقعیت واقعی: داری روی یک قابلیت کار می‌کنی و وسط کار متوجه یک غلط املایی در فایلی بی‌ربط می‌شوی و درستش می‌کنی. حالا پوشهٔ کاری‌ات دو تغییر نامرتبط دارد. اگر همه را در یک commit بگذاری، تاریخچه‌ات دروغ می‌گوید و بعداً اگر بخواهی فقط یکی را برگردانی، نمی‌توانی.

The answer: the staging area lets you design a commit, not merely record one. A real situation: you are working on a feature, notice a typo in an unrelated file, and fix it. Your working tree now holds two unrelated changes. Put them in one commit and your history lies — and later, if you want to revert only one of them, you cannot.

با ناحیهٔ آماده‌سازی، اول غلط املایی را add و commit می‌کنی، بعد قابلیت را. دو commit تمیز، هرکدام با یک دلیل روشن. این همان چیزی است که در فصل ۱۴ به آن می‌گوییم «commit اتمی» و در code review تفاوتش را حس می‌کنی.

With staging you add and commit the typo first, then the feature. Two clean commits, each with a single clear reason. That is what chapter 14 calls an “atomic commit”, and you feel the difference during code review.

اولین مخزنYour first repository

حالا همهٔ آنچه گفتیم را با دست می‌سازیم و با چشم می‌بینیم. هیچ‌کدام از این دستورها به چیزی روی سیستمت آسیب نمی‌زند.

Now we build everything we described by hand and look at it. None of these commands can harm anything on your system.

اول به Git بگو تو که هستی. این کار فقط یک‌بار لازم است، و دلیلش این است که هر commit نام و ایمیل نویسنده را داخل خودش ذخیره می‌کند — یادت هست که کلید commit از محتوایش ساخته می‌شود؟ پس نام تو هم بخشی از آن کلید است.

First tell Git who you are. This is needed only once, and the reason is that every commit stores the author's name and email inside itself — remember that a commit's key is derived from its content? So your name is part of that key.

# ‏--global یعنی برای همهٔ مخزن‌های این کاربر، نه فقط این پروژه.
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# نام شاخهٔ پیش‌فرض. اگر این را نگذاری، Git هشدار می‌دهد.
git config --global init.defaultBranch main

# ببین چه چیزی تنظیم شده و از کدام فایل آمده — سوئیچ --show-origin طلاست
# وقتی می‌خواهی بفهمی یک تنظیم عجیب از کجا آمده.
git config --list --show-origin

حالا یک مخزن بساز:

Now create a repository:

mkdir git-lab
cd git-lab
git init
Initialized empty Git repository in /home/you/git-lab/.git/

git init فقط یک کار کرد: یک پوشهٔ پنهان به نام .git ساخت. تمام مخزن تو همان پوشه است — نه بیشتر. اگر آن را پاک کنی، پروژه‌ات می‌ماند ولی تاریخچه‌اش کاملاً می‌رود. اگر کپی‌اش کنی، کل تاریخچه را کپی کرده‌ای.

git init did exactly one thing: it created a hidden folder called .git. Your entire repository is that folder — nothing more. Delete it and your project remains but its history is gone entirely. Copy it and you have copied the whole history.

ls -1 .git
HEAD
config
description
hooks/
info/
objects/
refs/

# ‏objects خالی است — هنوز هیچ محتوایی ذخیره نکرده‌ایم.
ls .git/objects
info  pack

اولین فایل، مرحله‌به‌مرحله

The first file, step by step

printf 'hello\n' > a.txt
git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	a.txt

nothing added to commit but untracked files present (use "git add" to track)

کلمهٔ کلیدی اینجا Untracked است: Git این فایل را می‌بیند ولی دنبالش نمی‌کند. Git هیچ‌وقت خودسرانه چیزی را ردیابی نمی‌کند — تو باید صریح بگویی. این تصمیم عمدی است، چون پوشهٔ پروژه پر از چیزهایی است که نباید در تاریخچه باشند: خروجی بیلد، فایل موقت، رمز.

The key word is Untracked: Git can see the file but is not following it. Git never tracks anything on its own initiative — you must say so explicitly. That is deliberate, because a project folder is full of things that must not be in history: build output, temporary files, secrets.

git add a.txt

# حالا نگاه کن به .git/objects — چیزی اضافه شده است!
find .git/objects -type f
.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a

توجه کن که هنوز commit نزده‌ایم، اما محتوا همین الان در پایگاه‌داده است. git add فقط «علامت‌گذاری» نیست؛ واقعاً محتوا را ذخیره می‌کند. این را نگه دار — در فصل ۱۰ می‌بینی که چرا همین باعث می‌شود کارِ addشده تقریباً هیچ‌وقت گم نشود.

Note that we have not committed yet, and the content is already in the database. git add is not merely “marking”; it genuinely stores content. Hold on to this — in chapter 10 you will see why it means staged work is almost never truly lost.

# نوع این شیء چیست؟
git cat-file -t ce013625030ba8dba906f756967f9e9ca394464a
blob

# محتوایش چیست؟ سوئیچ -p یعنی «چاپ خوانا»
git cat-file -p ce013625030ba8dba906f756967f9e9ca394464a
hello

حالا commit بزنیم و ببینیم چه چیز دیگری ساخته می‌شود:

Now let us commit and see what else gets created:

# ‏-m یعنی پیام را همین‌جا می‌دهم، وگرنه ویرایشگر باز می‌شود.
git commit -m "افزودن اولین فایل"
[main (root-commit) 663808a] افزودن اولین فایل
 1 file changed, 1 insertion(+)
 create mode 100644 a.txt

# حالا سه شیء داریم، نه یکی
find .git/objects -type f | wc -l
3

سه شیء: blobی که داشتیم، به‌اضافهٔ یک tree (که می‌گوید نام a.txt به آن blob اشاره می‌کند) و یک commit. بیایید زنجیره را از بالا دنبال کنیم:

Three objects: the blob we had, plus a tree (recording that the name a.txt points at that blob) and a commit. Let us follow the chain from the top:

# ‏HEAD یعنی «آخرین commit شاخهٔ فعلی»
git cat-file -p HEAD
tree 2e81171448eb9f2ee3821e3d447aa6b2fe3ddba1
author Your Name <you@example.com> 1757376000 +0330
committer Your Name <you@example.com> 1757376000 +0330

افزودن اولین فایل

# نحو ^{tree} یعنی «آن tree که این commit به آن اشاره می‌کند»
git cat-file -p HEAD^{tree}
100644 blob ce013625030ba8dba906f756967f9e9ca394464a	a.txt

این خط آخر، کل مدل داده را در یک خط نشان می‌دهد. از راست به چپ بخوانش: نام a.txt، که یک blob است، با کلید ce0136… — همان کلیدی که ده دقیقه پیش، قبل از ساختن هیچ مخزنی، با hash-object حسابش کردیم. عدد 100644 هم مجوز فایل است (فایل معمولی، غیراجرایی).

That last line shows the entire data model in one line. Read it: the name a.txt, which is a blob, with key ce0136… — the same key we computed ten minutes ago with hash-object, before any repository existed. The 100644 is the file mode (an ordinary, non-executable file).

خواندن تاریخچهReading history

تاریخچه‌ای که نتوانی بخوانی، فایده‌ای ندارد. سه دستور برای نود درصد کارها کافی است.

A history you cannot read is worthless. Three commands cover ninety percent of the work.

اول یک commit دوم بسازیم تا چیزی برای مقایسه داشته باشیم:

First let us make a second commit so we have something to compare:

printf 'سلام\n' > b.txt
git add b.txt
git commit -m "افزودن نسخهٔ فارسی"

# ‏--oneline: یک خط برای هر commit. برای مرور سریع بهترین است.
# ‏--graph: شکل شاخه‌ها را با خط می‌کشد — از فصل ۵ به بعد حیاتی می‌شود.
git log --oneline --graph
* 4f1c2d8 افزودن نسخهٔ فارسی
* 663808a افزودن اولین فایل

# قالب دلخواه: چه کسی، کِی، چه چیزی. %h کلید کوتاه، %an نویسنده،
# ‏%ar زمان نسبی («۳ روز پیش») و %s خط اول پیام است.
git log --pretty=format:'%h  %an  %ar  %s'
4f1c2d8  Your Name  2 minutes ago  افزودن نسخهٔ فارسی
663808a  Your Name  5 minutes ago  افزودن اولین فایل

و برای دیدن اینکه دقیقاً چه چیزی عوض شد:

And to see exactly what changed:

# تفاوت پوشهٔ کاری با ناحیهٔ آماده‌سازی — یعنی «چه چیزی add نکرده‌ام؟»
git diff

# تفاوت ناحیهٔ آماده‌سازی با آخرین commit — یعنی «چه چیزی commit خواهد شد؟»
# این را همیشه قبل از commit بزن. عادت خوبی است که جلوی خیلی اشتباه‌ها را می‌گیرد.
git diff --staged

# یک commit مشخص چه کرد؟
git show 663808a

چیزهایی که نباید ردیابی شوندWhat should never be tracked

یک قاعدهٔ ساده: اگر چیزی را می‌شود دوباره ساخت، یا اگر نباید کسی ببیندش، در Git نمی‌رود.

One simple rule: if it can be regenerated, or if nobody should see it, it does not go into Git.

# وابستگی‌ها — با یک دستور دوباره نصب می‌شوند، پس ذخیره‌شان اتلاف است
node_modules/
venv/

# خروجی بیلد — از روی کد ساخته می‌شود، پس منبعش کافی است
dist/
build/
*.o

# رمز و کلید — هرگز. حتی یک بار. بخش «دام‌ها» را ببین.
.env
*.pem

# فایل‌های سیستم‌عامل و ویرایشگر
.DS_Store
Thumbs.db
.vscode/

# استثنا: با ! می‌شود یک فایل را از قاعدهٔ بالا مستثنی کرد
# اینجا: کل .vscode نادیده گرفته شود جز فایل تنظیمات مشترک تیم
!.vscode/settings.json

نکتهٔ مهمی که خیلی‌ها دیر می‌فهمند: .gitignore فقط روی فایل‌های ردیابی‌نشده اثر دارد. اگر فایلی را یک‌بار commit کرده باشی، اضافه کردنش به .gitignore هیچ کاری نمی‌کند — Git همچنان دنبالش می‌کند. دلیلش منطقی است: Git فرض می‌کند اگر تو عمداً چیزی را ردیابی کرده‌ای، نمی‌خواهی بی‌سروصدا رهایش کند.

A point many people learn late: .gitignore only affects untracked files. If you have already committed a file, adding it to .gitignore does nothing — Git keeps following it. The reasoning is sound: Git assumes that if you deliberately tracked something, you do not want it silently abandoned.

# رها کردن یک فایل از ردیابی، بدون حذفش از دیسک.
# ‏--cached یعنی «فقط از index حذف کن، به پوشهٔ کاری دست نزن».
# بدون --cached فایل واقعاً پاک می‌شود.
git rm --cached .env
git commit -m "حذف .env از ردیابی"

# چرا این فایل نادیده گرفته شد؟ کدام قاعده باعثش شد؟
# وقتی .gitignore بزرگ می‌شود، این دستور وقت زیادی از تو می‌خرد.
git check-ignore -v dist/app.js
.gitignore:6:dist/	dist/app.js

کجا خراب می‌شودWhere it breaks

شش خطایی که تقریباً همه در هفتهٔ اول می‌بینند. پیام خطا را دقیق آورده‌ایم تا وقتی همان را دیدی، بشناسی‌اش.

Six errors nearly everyone meets in their first week. The exact messages are here so you recognise them when they appear.

مرجع سریع این فصلQuick reference

تمرین‌هاExercises

دوازده تمرین، از ساده به سخت. همه پاسخ کامل دارند — اما اول خودت انجامش بده. برای همه‌شان یک پوشهٔ خالی کافی است؛ هیچ‌کدام به اینترنت نیاز ندارند.

Twelve exercises, easy to hard. All have full solutions — but do them yourself first. An empty folder is all you need; none of them require the internet.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

git config user.name
Your Name

git config --list --show-origin | grep user.name
file:/home/you/.gitconfig	user.name=Your Name

mkdir ex-1-2 && cd ex-1-2
git init
find .git/objects -type f | wc -l
0

printf 'first line\n' > notes.txt
git status --short
?? notes.txt          ← ?? یعنی Untracked

git add notes.txt
git status --short
A  notes.txt          ← A یعنی Added، در ستون اول = ناحیهٔ آماده‌سازی

git commit -m "افزودن یادداشت"
git status --short
                      ← خالی یعنی هر سه ناحیه یکسان‌اند

git log --oneline
a3f9c21 افزودن یادداشت

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

# بدون خط جدید، کلید کاملاً فرق می‌کند:
printf 'hello' | git hash-object --stdin
b6fc4c620b67d95f953a5c1c1230aaab5db5a1b0

mkdir ex-1-5 && cd ex-1-5 && git init -q
printf 'hello\n' > a.txt

find .git/objects -type f | wc -l
0                     ← هنوز هیچ چیزی ذخیره نشده

git add a.txt
find .git/objects -type f
.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a

# بدون هیچ commit ای، محتوا قابل بازیابی است:
git cat-file -p ce013625030ba8dba906f756967f9e9ca394464a
hello

git log
fatal: your current branch 'main' does not have any commits yet

printf 'version A\n' > f.txt
git add f.txt
printf 'version B\n' > f.txt

git status --short
AM f.txt
    ↑↑
    │└─ ستون دوم: M یعنی در پوشهٔ کاری تغییر کرده (version B)
    └── ستون اول: A یعنی در ناحیهٔ آماده‌سازی اضافه شده (version A)

git diff --staged
+version A             ← این چیزی است که commit می‌شود

git diff
-version A
+version B             ← این چیزی است که جا می‌ماند

git commit -m "test"
git show HEAD:f.txt
version A

mkdir ex-1-7 && cd ex-1-7 && git init -q
printf 'same\n' > one.txt
printf 'same\n' > two.txt
git add . && git commit -q -m "دو فایل، یک محتوا"

# همهٔ اشیا را با نوعشان فهرست کن
git cat-file --batch-check --batch-all-objects
1275430f… blob 5
8a9d2e4… tree 74
c5e1f30… commit 178

git cat-file -p HEAD^{tree}
100644 blob 1275430f…	one.txt
100644 blob 1275430f…	two.txt
       ↑ همان کلید، دو بار

mkdir ex-1-8 && cd ex-1-8 && git init -q
printf 'KEY=123\n' > secret.env
printf '*.log\n*.env\n!example.env\n' > .gitignore

git status --short
?? .gitignore         ← secret.env نیست، یعنی نادیده گرفته شد

git check-ignore -v secret.env
.gitignore:2:*.env	secret.env
           ↑ خط ۲، قاعدهٔ *.env

mkdir ex-1-9 && cd ex-1-9 && git init -q
printf 'KEY=123\n' > config.env
git add config.env && git commit -q -m "اشتباه: افزودن config"

# حالا سعی می‌کنیم نادیده‌اش بگیریم
printf '*.env\n' > .gitignore
printf 'KEY=456\n' > config.env
git status --short
 M config.env         ← هنوز ردیابی می‌شود! .gitignore بی‌اثر بود

# درمان: از index بیرونش بیاور، ولی روی دیسک نگهش دار
git rm --cached config.env
rm 'config.env'

git commit -q -m "حذف config.env از ردیابی"
git status --short
                      ← تمیز است، چون حالا .gitignore کار می‌کند

ls config.env
config.env            ← فایل هنوز روی دیسک است

mkdir ex-1-10 && cd ex-1-10 && git init -q
mkdir src
printf 'hello\n' > src/app.txt
git add . && git commit -q -m "شروع"

# قدم ۱ — commit به ما کلید tree ریشه را می‌دهد
git cat-file -p HEAD
tree 5a1b8c9…
author …

# قدم ۲ — tree ریشه: یک زیرپوشه دارد
git cat-file -p 5a1b8c9…
040000 tree 7d2e4f1…	src
       ↑ نوع tree یعنی این یک پوشه است، نه فایل

# قدم ۳ — tree زیرپوشه: بالاخره یک blob
git cat-file -p 7d2e4f1…
100644 blob ce013625…	app.txt

# قدم ۴ — محتوا
git cat-file -p ce013625030ba8dba906f756967f9e9ca394464a
hello

# زمان را ثابت می‌کنیم. این خودش نکته است: زمان بخشی از محتوای commit است،
# پس بدون ثابت کردنش نمی‌شود دو تاریخچه را منصفانه مقایسه کرد.
export GIT_AUTHOR_DATE="2020-01-01T00:00:00"
export GIT_COMMITTER_DATE="2020-01-01T00:00:00"

# تاریخچهٔ اصلی
mkdir orig && cd orig && git init -q
printf 'A\n' > f.txt && git add . && git commit -q -m "c1"
printf 'B\n' > g.txt && git add . && git commit -q -m "c2"
printf 'C\n' > h.txt && git add . && git commit -q -m "c3"
git log --format=%H > ../before.txt
cd ..

# همان تاریخچه، ولی فقط محتوای اولین commit عوض شده
mkdir tampered && cd tampered && git init -q
printf 'A-tampered\n' > f.txt && git add . && git commit -q -m "c1"
printf 'B\n' > g.txt && git add . && git commit -q -m "c2"
printf 'C\n' > h.txt && git add . && git commit -q -m "c3"
git log --format=%H > ../after.txt
cd ..

# چند کلید مشترک است؟
comm -12 <(sort before.txt) <(sort after.txt) | wc -l
0                     ← هیچ‌کدام. حتی c2 و c3 که دست‌نخورده بودند.

mkdir ex-1-12 && cd ex-1-12 && git init -q

# ۱) محتوا را به یک blob تبدیل کن. سوئیچ -w یعنی «بنویسش»، نه فقط حساب کن.
printf 'hello\n' | git hash-object -w --stdin
ce013625030ba8dba906f756967f9e9ca394464a

# ۲) به index بگو این blob اسمش a.txt است. اینجاست که نام به محتوا وصل می‌شود.
# ‏100644 مجوز فایل معمولی است.
git update-index --add --cacheinfo 100644 \
  ce013625030ba8dba906f756967f9e9ca394464a a.txt

# ۳) از index یک شیء tree بساز
git write-tree
2e81171448eb9f2ee3821e3d447aa6b2fe3ddba1

# ۴) از tree یک commit بساز. بدون -p یعنی این commit والد ندارد.
echo "اولین commit دستی" | \
  git commit-tree 2e81171448eb9f2ee3821e3d447aa6b2fe3ddba1
7b1e4a2…

# ۵) شاخهٔ فعلی را به این commit اشاره بده.
# ‏HEAD می‌نویسیم نه refs/heads/main، چون نام شاخهٔ پیش‌فرض ممکن است
# روی سیستم تو master باشد. این شکل، هرچه باشد درست کار می‌کند.
git update-ref HEAD 7b1e4a2…

git log --oneline
7b1e4a2 اولین commit دستی

git status --short
 D a.txt               ← حذف‌شده؟! این درست است — پایین توضیح داده شده

# فایل را از خودِ commit بیرون بکش تا پوشهٔ کاری هم بخواند
git checkout .
git status --short
                      ← حالا تمیز است
cat a.txt
hello

پروژهٔ پایان فصلEnd-of-chapter project

# ۱) پایه — .gitignore اول
mkdir notebook && cd notebook && git init -q
printf '*.tmp\ndrafts/\n' > .gitignore
git add .gitignore
git commit -q -m "افزودن قواعد نادیده‌گرفتن"

# ۲) سه commit با معنا
printf '# خرید\n- نان\n' > shopping.md
git add shopping.md && git commit -q -m "افزودن فهرست خرید"

printf '# کتاب‌ها\n- سووشون\n' > books.md
git add books.md && git commit -q -m "افزودن فهرست کتاب"

printf '# ایده‌ها\n- یادگیری Git\n' > ideas.md
git add ideas.md && git commit -q -m "افزودن فهرست ایده‌ها"

# ۳) دو تغییر نامرتبط، دو commit جدا
printf '# سفر\n- شیراز\n' > travel.md      # تغییر اول
printf '# خرید\n- نان سنگک\n' > shopping.md    # تغییر دوم

# فقط اصلاح غلط را stage کن — نه فایل جدید را
git add shopping.md
git diff --staged --stat
 shopping.md | 2 +-      ← فقط همین یکی، درست است
git commit -q -m "اصلاح: نان سنگک به‌جای نان"

# حالا فایل جدید
git add travel.md
git commit -q -m "افزودن فهرست سفر"

# ۴) آزمون نادیده‌گرفتن
printf 'موقت\n' > scratch.tmp
mkdir drafts && printf 'پیش‌نویس\n' > drafts/idea.md

git status --short
                      ← خالی: هیچ‌کدام دیده نمی‌شوند

git check-ignore -v scratch.tmp drafts/idea.md
.gitignore:1:*.tmp	scratch.tmp
.gitignore:2:drafts/	drafts/idea.md

# ۵) گزارش تاریخچه — %h کلید کوتاه، %s پیام
git log --pretty=format:'- `%h` %s' --shortstat > HISTORY.md
git add HISTORY.md && git commit -q -m "افزودن گزارش تاریخچه"

git log --oneline
e2c4a91 افزودن گزارش تاریخچه
7d1b3f8 افزودن فهرست سفر
4a9e2c1 اصلاح: نان سنگک به‌جای نان
b3f7d20 افزودن فهرست ایده‌ها
9c1a4e6 افزودن فهرست کتاب
2f8d5b3 افزودن فهرست خرید
1a4c7e9 افزودن قواعد نادیده‌گرفتن