Staging — ناحیه آماده‌سازی در Git

Working Directory --(git add)--> Staging Area --(git commit)--> Repository

git add hello.txt

git add hello.txt README.md app.py

git add .

نقطه (.) یعنی «همه فایل‌ها و تغییرات پوشه فعلی». این رایج‌ترین شکل استفاده از git add است.

افزودن کل پوشه پروژه (از هر جای مخزن)

git add -A

بعد از git add چه می‌شود؟

فرض کنید hello.txt را اضافه کرده‌اید:

git add hello.txt
git status

خروجی:

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   hello.txt

حالا فایل در وضعیت Staged است و آماده کامیت! (کامیت را در مبحث بعدی یاد می‌گیریم)

برگرداندن فایل از Staging

اگر اشتباهاً فایلی را Stage کردید و پشیمان شدید:

git restore --staged hello.txt

این دستور فایل را از ناحیه staging برمی‌گرداند (به untracked یا modified برمی‌گردد) — به خود فایل دست نمی‌زند.

چرا ناحیه Staging اصلاً وجود دارد؟

سؤال خوبی است! چرا مستقیم کامیت نمی‌کنیم؟ دلیلش کنترل دقیق است:

• کامیت‌های تمیز: فرض کنید ۵ فایل را ویرایش کرده‌اید که ۳ تای آن‌ها مربوط به یک باگ و ۲ تای دیگر مربوط به قابلیت جدید است. با staging می‌توانید آن‌ها را در دو کامیت جدا ثبت کنید — تاریخچه خواناتر می‌شود.
• بررسی نهایی: قبل از کامیت، فرصت دارید یک بار دیگر ببینید دقیقاً چه چیزی وارد تاریخچه می‌شود.
• کامیت بخشی از تغییرات: حتی می‌توانید بخشی از تغییرات داخل یک فایل را stage کنید (git add -p)!

مثال عملی: دو کامیت جداگانه

# سه فایل ویرایش شده‌اند: a.py (باگ)، b.py (باگ)، c.py (قابلیت جدید)

# کامیت اول: فقط فایل‌های مربوط به باگ
git add a.py b.py
git commit -m "رفع باگ ورود کاربر"

# کامیت دوم: فایل قابلیت جدید
git add c.py
git commit -m "افزودن قابلیت جستجو"

خلاصه

• گیت سه ناحیه دارد: Working Directory، Staging Area و Repository
• git add تغییرات را به ناحیه staging می‌آورد
• git add . همه تغییرات را stage می‌کند
• git restore --staged فایل را از staging برمی‌گرداند
• staging به شما اجازه می‌دهد کامیت‌های کوچک و تمیز داشته باشید