تا اینجای کار، گیت روی سیستم شما نصب شده و هویتتان هم برایش کاملاً روشن است؛ اما تمام این‌ها مثل داشتن یک ماشین زمان بدون دکمه استارت است!

تا زمانی که یاد نگیرید چطور یک پروژه را زیر نظر این ابزار بیاورید، هیچ تغییری ثبت نخواهد شد. در این درس، قرار است یاد بگیرید چطور به یک پوشه معمولی روی هارد دیسک خود، «هوش اصیل گیت» را تزریق کنید تا از یک دایرکتوری ساده، به یک مخزن زنده و هوشمند تبدیل شود.

بسیاری از برنامه‌نویسان فکر می‌کنند کار با گیت فقط حفظ کردن چند دستور متنی است، اما راز موفقیت در این ابزار، داشتن یک دید راداری نسبت به وضعیت فایل‌هاست.

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

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

ساخت یک مخزن (Repository) جدید با دستور Git Init

برای اینکه بتوانید از قابلیت‌های گیت در پروژه خود استفاده کنید، ابتدا باید آن پوشه را به یک مخزن یا اصطلاحاً ریپازیتوری (Repository) تبدیل کنید. مخزن در واقع همان پوشه پروژه شماست، با این تفاوت که گیت تمام فایل‌ها و تاریخچه تغییرات آن را به طور کامل زیر نظر دارد.

قدم اول: ورود به پوشه پروژه در ترمینال

قبل از اجرای هر دستوری، باید در محیط ترمینال یا Git Bash به مسیر پوشه پروژه خود بروید. برای این کار از دستور cd استفاده می‌شود. فرض کنید پوشه پروژه‌تان در دسکتاپ و نام آن my_project است:

cd Desktop/my_project

قدم دوم: تزریق گیت به پروژه

حالا که در مسیر درست قرار دارید، کافی است دستور زیر را تایپ کرده و کلید اینتر را بزنید:

git init

با اجرای این دستور، گیت کار خود را آغاز می‌کند و پیغامی مشابه عبارت زیر را در ترمینال به شما نشان می‌دهد:

Initialized empty Git repository in /path/to/your/project/.git/

درون پوشه پنهان .git چه می‌گذرد؟

وقتی دستور git init را اجرا می‌کنید، در ظاهر هیچ تغییری در پوشه پروژه شما ایجاد نمی‌شود. اما اگر فایل‌های پنهان (Hidden Files) سیستم‌عامل خود را فعال کنید، متوجه می‌شوید که یک پوشه جدید و پنهان به نام .git در ریشه پروژه شما ساخته شده است.

این پوشه، مغز متفکر و قلب تپنده پروژه شما در گیت است. تمام جزییات مربوط به کامیت‌ها، تاریخچه تغییرات، مشخصات نویسنده کدها، شاخه‌ها (Branches) و تنظیمات اختصاصی این پروژه در همین پوشه ذخیره می‌شود.

به هیچ وجه نباید محتویات این پوشه را به صورت دستی دست‌کاری یا حذف کنید؛ چرا که با پاک شدن پوشه .git، کل تاریخچه پروژه شما برای همیشه نابود می‌شود و آن پوشه دوباره به یک دایرکتوری معمولی و بدون گذشته تبدیل خواهد شد.

بررسی وضعیت فایل‌ها با دستور Git Status

پس از اینکه گیت را در پروژه خود فعال کردید، به یک ابزار نظارتی نیاز دارید تا در هر لحظه، تغییرات فایل‌ها را به شما گزارش دهد. دستور git status پرکاربردترین و حیاتی‌ترین دستور در تمام دوران برنامه‌نویسی شما خواهد بود. این دستور مانند یک رادار دقیق، وضعیت فعلی مخزن را بررسی کرده و فایل‌های دست‌کاری‌شده، حذف‌شده یا جدید را به شما نشان می‌دهد.

بگذارید ساده بگم؛ قبل از انجام هر کاری در گیت، ابتدا باید وضعیت پروژه را چک کنید تا بدانید در چه نقطه‌ای ایستاده‌اید. برای اجرای این رادار، کافی است دستور زیر را در ترمینال بنویسید:

git status

تحلیل خروجی‌های مختلف Git Status

وقتی این دستور را اجرا می‌کنید، گیت بر اساس وضعیت فایل‌های شما، پاسخ‌های متفاوتی در ترمینال چاپ می‌کند:

حالت اول: مخزن کاملاً تمیز است (Nothing to commit)

اگر هیچ فایلی را تغییر نداده باشید یا همه تغییرات را قبلاً ثبت کرده باشید، گیت پیغام زیر را نمایش می‌دهد:

On branch main
nothing to commit, working tree clean

این پیغام یعنی پوشه کاری شما با مخزن نهایی کاملاً هم‌راستا است و می‌توانید با خیال راحت کدنویسی را ادامه دهید.

حالت دوم: وجود فایل‌های ردیابی‌نشده (Untracked files)

اگر یک فایل جدید (مثلاً index.html) در پوشه پروژه بسازید و دوباره دستور را اجرا کنید، گیت متوجه حضور این فایل جدید می‌شود اما چون هنوز آن را به محیط آماده‌سازی نفرستاده‌اید، آن را در دسته‌بندی Untracked قرار می‌دهد و نام فایل را به رنگ قرمز نمایش می‌دهد:

On branch main
Untracked files:
(use "git add ..." to include in what will be committed)
index.html

خروجی خلاصه و سریع

در پروژه‌های بزرگ که تعداد فایل‌های تغییریافته زیاد است، خروجی پیش‌فرض git status ممکن است طولانی و شلوغ شود. برای اینکه یک گزارش سریع، فشرده و خلاصه از وضعیت فایل‌ها داشته باشید، می‌توانید از سوئیچ -s (مخفف Short) استفاده کنید:

git status -s

در این حالت، گیت یک خروجی بسیار مختصر با کدهای رنگی و نشانه‌های اختصاری (مانند ?? برای فایل‌های ردیابی‌نشده) به شما تحویل می‌دهد تا در یک نگاه، وضعیت کل پروژه را ارزیابی کنید.

درک عمیق چهار وضعیت فایل‌ها در گیت

برای اینکه بتوانید بدون سردرگمی با گیت کار کنید، باید منطق پشت پرده آن را درک کنید. گیت یک فایل را فقط به عنوان «یک تکه متن» نمی‌بیند؛ بلکه برای هر فایل یک چرخه حیات و موقعیت مشخص در نظر می‌گیرد. به طور کلی، هر فایلی که درون پوشه پروژه شما قرار دارد، در یکی از این چهار وضعیت قرار می‌گیرد.

اصل حرف این است: تا زمانی که تغییر وضعیت این فایل‌ها را درک نکنید، مدیریت کامیت‌ها و بازگرداندن کدهای قدیمی برایتان غیرممکن خواهد بود.

۱. وضعیت ردیابی‌نشده (Untracked)

این وضعیت متعلق به فایل‌های جدیدی است که به تازگی در پوشه پروژه ایجاد کرده‌اید، اما هنوز به گیت معرفی نشده‌اند. فرض کن یک فایل پایتون به نام views.py می‌سازید؛ گیت متوجه حضور این فایل در پوشه می‌شود، اما تا زمانی که خودتان به صورت دستی دستور ثبت آن را صادر نکنید، هیچ‌گونه تاریخچه یا پشتیبانی از این فایل تهیه نخواهد کرد. این فایل‌ها در خروجی دستور استاتوس با رنگ قرمز و در دسته Untracked قرار می‌گیرند.

۲. وضعیت تغییریافته (Modified)

این حالت زمانی رخ می‌دهد که یک فایل از قبل توسط گیت ردیابی شده و در کامیت‌های قبلی وجود داشته است، اما شما دست به کار شده‌اید و کدهای درون آن را ویرایش، حذف یا اضافه کرده‌اید. در این حالت، گیت کدهای جدید را با آخرین نسخه ذخیره‌شده مقایسه کرده و فایل را در وضعیت Modified قرار می‌دهد. این یعنی تغییرات ایجاد شده‌اند اما هنوز برای ثبت نهایی بسته‌بندی نشده‌اند.

۳. وضعیت آماده‌سازی‌شده (Staged)

این یک لایه واسط و بسیار هوشمندانه در گیت است. وقتی فایلی را تغییر می‌دهید یا فایل جدیدی می‌سازید، قبل از ثبت نهایی باید آن را به صف انتظار بفرستید. وضعیت Staged یعنی شما این فایل را انتخاب کرده‌اید تا در نسخه بعدی (کامیت بعدی) پروژه حضور داشته باشد.

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

۴. وضعیت تغییرنیافته (Unmodified)

وقتی فایل‌های موجود در صف انتظار (Staging Area) را به صورت نهایی ثبت و کامیت می‌کنید، کار گیت با آن نسخه از فایل‌ها تمام می‌شود. از این لحظه به بعد، فایل‌ها به وضعیت Unmodified یا همان تغییرنیافته برمی‌گردند.

این یعنی آخرین ویرایش فایل با آنچه در مخزن گیت ذخیره شده، کاملاً یکسان است و پروژه در تمیزترین حالت ممکن قرار دارد. چرخه حیات فایل دوباره از همین‌جا شروع می‌شود؛ یعنی به محض اینکه یکی از این فایل‌ها را ویرایش کنید، وضعیت آن از Unmodified به Modified تغییر خواهد کرد.

ارتباط دستورات با محیط‌های سه‌گانه گیت

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

فرض کنید می‌خواهید یک بسته پستی ارسال کنید؛ ابتدا کالا را روی میز کار خود می‌گذارید (محیط اول)، سپس آن را درون جعبه قرار می‌دهید و چسب می‌زنید (محیط دوم) و در نهایت آن را به مامور پست تحویل می‌دهید تا ارسال شود (محیط سوم). گیت دقیقاً همین رویه را طی می‌کند.

۱. پوشه کاری (Working Directory)

این همان پوشه فیزیکی پروژه شما روی هارد دیسک است؛ جایی که فایل‌ها را با ویرایشگر کد باز می‌کنید، خطوط جدید می‌نویسید یا فایلی را پاک می‌کنید. تمام فایل‌های این محیط یا در وضعیت ردیابی‌نشده (Untracked) هستند یا دست‌کاری شده‌اند و در وضعیت تغییریافته (Modified) قرار دارند. گیت در این محیط فقط ناظر تغییرات شماست و هیچ چیزی را ذخیره نمی‌کند.

۲. محیط آماده‌سازی (Staging Area)

این محیط که به آن Index هم می‌گویند، یک لایه واسط و نامرئی بین پوشه کاری و مخزن نهایی است. وقتی کارتان با بخشی از کدها تمام می‌شود، با اجرای دستور git add آن‌ها را به این محیط می‌فرستید. فایل‌های این بخش در وضعیت آماده‌سازی‌شده (Staged) قرار می‌گیرند. این لایه به شما اجازه می‌دهد تا تصمیم بگیرید کدام تغییرات دقیقاً در بسته‌بندی بعدی قرار بگیرند و کدام فایل‌ها فعلاً در پوشه کاری باقی بمانند.

۳. مخزن محلی (Local Repository)

این لایه همان پوشه پنهان .git است. وقتی از کامل بودن تغییرات در محیط استیج مطمئن شدید، دستور git commit را اجرا می‌کنید. با این کار، گیت تمام فایل‌های موجود در محیط آماده‌سازی را برمی‌دارد، آن‌ها را به عنوان یک نسخه دایمی و فشرده با یک شناسه منحصربه‌فرد ثبت می‌کند. فایل‌ها پس از این دستور به وضعیت تغییرنیافته (Unmodified) بازمی‌گردند.

این زنجیره چطور در عمل کار می‌کند؟

وقتی دستور git status را اجرا می‌کنید، گیت در واقع تفاوت‌های میان این سه محیط را به شما نشان می‌دهد:

  • اگر فایلی در پوشه کاری با محیط استیج فرق داشته باشد، گیت آن را قرمز (Modified) نشان می‌دهد.
  • اگر فایلی در محیط استیج با آخرین کامیتِ مخزن محلی تفاوت داشته باشد، آن را سبز (Staged) نمایش می‌دهد.

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