آموزش گیت پروژه محور

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

برای حل ریشه‌ای این مشکل، ابزارهای سیستم کنترل نسخه (Version Control System) به وجود آمدند. منطق این ابزارها بسیار ساده اما فوق‌العاده هوشمندانه است:

به جای اینکه برای هر تغییر کوچک کل پوشه یا فایل را کپی کنی، یک سیستم کنترل نسخه مانند Git از وضعیت کدها در لحظات کلیدی یک Snapshot (عکس‌برداری از لحظه) می‌گیرد.

پیش از شروع کار باید مرز و نقش ابزارها کاملاً شفاف باشد. اشتباه گرفتن Git و GitHub یکی از رایج‌ترین سوءتفاهم‌ها میان تازه‌کاران است:

وقتی کدی را با Git روی رایانه خود ثبت می‌کنی، این ثبت فقط در حافظه سیستم خودت قرار دارد. تا زمانی که آن را به سرویسی مثل GitHub آپلود (Push) نکنی، به‌صورت آنلاین یا روی سیستم دیگران قرار نمی‌گیرد.

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

فایل‌های همراه دوره در مخزن رسمی آموزش گیت پروژه محور قرار دارند. ابتدا بستهٔ شروع هنرجو را دانلود کن؛ اگر دانلود مستقیم باز نشد، صفحهٔ فایل ZIP را باز کن و Download raw file را بزن.

فقط همین بستهٔ شروع را بگیر؛ Code → Download ZIP کل مخزن رسمی را دانلود می‌کند و بستهٔ تمرین نیست. مخزن رسمی را برای شروع clone یا fork نکن؛ تاریخچهٔ پروژهٔ خودت را در درس‌ها از صفر می‌سازی.

بسته اولیه دوره را استخراج کن و پوشه simorgh-journey را پیدا کن. در آغاز مسیر، تنها یک فایل آماده به نام index.html داخل پوشه قرار دارد:

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

اگر VS Code نصب نیست، ابتدا نسخه سیستم‌عامل خودت را از وب‌سایت رسمی code.visualstudio.com دریافت و نصب کن. در رایانه مدیریت‌شده از مسئول سیستم کمک بگیر. افزونه، حساب کاربری یا آشنایی با HTML برای این تمرین لازم نیست.

برای ویرایش کدها و اجرای دستورات ترمینال، باید پوشه پروژه را در محیط VS Code باز کنیم.

دستورات Git همواره روی پوشه‌ای اثر می‌گذارند که ترمینال در آن باز است. باید مطمئن شوی ترمینال دقیقاً داخل پوشه simorgh-journey قرار دارد.

pwd

Get-Location

فایل index.html را در VS Code باز کن. می‌خواهیم متن وضعیت کاروان را پیدا کرده و نخستین تغییر واقعی پروژه را ایجاد کنیم.

Status: The caravan is preparing to depart.

اکنون متن پیدا شده را تغییر می‌دهیم تا حضور کاتب دیجیتال در پروژه ثبت شود.

Status: The caravan has a digital scribe.

جمله جدید در مرورگر دیده می‌شود و فایل روی دیسک ذخیره شده است. اما هنوز پوشه پروژه به یک Repository تبدیل نشده است.

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

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

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

خیلی از اوقات نرم‌افزار Git از قبل روی سیستم‌عامل (مثلاً ابزارهای Xcode در مک یا همراه ابزارهای دیگر) نصب شده است. بنابراین پیش از دانلود فایل‌های سنگین، ابتدا حضور آن را آزمایش می‌کنیم.

git --version

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

xcode-select --install

sudo apt update && sudo apt install git -y

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

git --version

سیستم‌عامل چگونه می‌داند وقتی دستور git را تایپ می‌کنی، کدام برنامه روی دیسک اجرا شود؟ این کار از طریق متغیری به نام PATH انجام می‌شود.

Get-Command git

command -v git

هیچ برنامه‌نویسی در دنیا تمام پرچم‌ها و دستورات فرعی Git را حفظ نمی‌کند! Git یک سیستم راهنمای عالی و داخلی همراه خود دارد:

git --help

git help status

فرآیند نصب Git به پایان رسیده است، اما با تایپ دستور git در ترمینال هنوز خطای command not found یا unrecognized command ظاهر می‌شود. نخستین بررسی‌های منطقی شما چیست؟

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

در دنیای توسعه نرم‌افزار، وقتی ده‌ها برنامه‌نویس روی یک پروژه بزرگ کار می‌کنند، هر تغییر (Commit) مثل برگی از شناسنامه پروژه است. اگر تغییری باعث ایجاد باگ شود یا نیاز به قدردانی از سازنده یک ویژگی باشد، سیستم باید بداند چه کسی آن تغییر را ایجاد کرده است.

نخستین قدم برای معرفی خود به سیستم، ثبت نام و نام خانوادگی به صورت سراسری (Global) است. پرچم --global به Git می‌گوید: «این نام را برای تمام پروژه‌های من روی این رایانه به یاد داشته باش.»

git config --global user.name "Your Full Name"

با اجرای این فرمان، Git یک فایل متنی ساده به نام .gitconfig در پوشه اصلی کاربر سیستم‌عامل (Home Directory) می‌سازد یا به‌روزرسانی می‌کند.

پس از نام، باید ایمیل خود را ثبت کنی. Git از ایمیل شما برای اتصال کامیت‌ها به آواتار شخصی (Gravatar) و پیوند دادن فعالیت‌های شما به حساب پلتفرم‌هایی مانند GitHub یا GitLab استفاده می‌کند.

git config --global user.email "your-email@example.com"

اگر تمایل نداری ایمیل واقعی‌ات به صورت عمومی در پروژه‌های متن‌باز نمایش داده شود، می‌توانی از ایمیل محرمانه noreply که GitHub در تنظیمات حساب کاربری‌ات ارائه می‌دهد استفاده کنی.

اگر مسیر رایانه مشترک را انتخاب کرده‌ای، فعلاً فقط مفهوم بازخوانی را بخوان؛ نبود هویت شخصی در global طبیعی است. معیار نهایی، بازخوانی هویت مؤثر پس از تنظیم local در درس چهارم است.

پس از اجرای دستورات کانفیگ، چگونه مطمئن شویم اطلاعات به درستی ذخیره شده‌اند؟ Git دستورات مشخصی برای استعلام مقادیر ذخیره‌شده دارد:

git config --global user.name

git config --global user.email

git config --global --get-regexp '^user[.]'

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

git config --list --show-origin

فرض کن در رایانه شخصی خود پروژه‌های شخصیت را با ایمیل شخصی پیش می‌بری، اما یک مخزن پروژه شرکت ساخته‌ای و می‌خواهی نام و ایمیل کاری‌ات فقط در همان مخزن ثبت شود بدون اینکه تنظیم سایر پروژه‌ها تغییر کند.

آیا ثبت نام و ایمیل در Git به این معنی است که هویت شما کاملاً اثبات شده و شخص دیگری نمی‌تواند با نام شما کامیت بزند؟ نام و ایمیل معمولی دقیقاً چه ماهیتی دارند؟

کاروان پرندگان به دهانه نخستین وادی از وادی‌های هفت‌گانه منطق‌الطیر، یعنی «وادی طلب»، رسیده است. تا این نقطه، پرندگان فقط درباره مقصد (سیمرغ) شنیده و ابزار پرواز را سنجیده‌اند، اما ورود واقعی به راه زمانی رخ می‌دهد که نخستین قدم برداشته شود. عطار دشواری و شکوه این آغاز را چنین توصیف می‌کند:

در دنیای برنامه‌نویسی، ساخت یک پوشه عادی به تنهایی کاری انجام نمی‌دهد. عمل واقعی در «وادی طلب»، اجرای فرمان git init است که آن پوشه معمولی را به یک مخزن محلی (Local Repository) زنده، هوشمند و قابل ردیابی تبدیل می‌کند.

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

git status

اکنون وقت آن است که طلسم پوشه معمولی را بشکنی! در ترمینال و داخل ریشه پروژه simorgh-journey فرمان زیر را اجرا کن:

git init

Initialized empty Git repository in /path/to/simorgh-journey/.git/

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

git config --local user.name "Your Full Name"
git config --local user.email "your-email@example.com"

با اجرای git init، یک پوشه مخفی به نام .git در پوشه پروژه ساخته می‌شود. این پوشه همان مغز و پایگاه داده Git است. فایل اصلی پروژه یعنی index.html بیرون آن در پوشه کاری (Working Tree) قرار دارد:

اکنون که دستور git init را اجرا کردی و ساختار پوشه مخفی .git را دیدی، عمیق‌تر تحلیل کن: این دستور دقیقا چه چیزی روی دیسک ساخته و چه کارهایی را هنوز انجام نداده است؟

حالا که مخزن محلی ساخته شده، فرمان git status را دوباره اجرا کن تا تغییر پیام ترمینال را در مقایسه با گام دوم ببینی:

git status

گاهی اوقات که تعداد فایل‌های پروژه زیاد می‌شود، خروجی کامل git status طولانی خواهد بود. Git یک پرچم فشرده به نام --short ارائه می‌دهد:

git status --short

رابط گرافیکی VS Code نیز همین وضعیت را به صورت بصری به شما نشان می‌دهد:

ممکن است این سوال برایت پیش بیاید که چرا Git پس از git init، فایل index.html را به صورت خودکار وارد تاریخچه نکرد و آن را در حالت Untracked باقی گذاشت؟

برای اطمینان از سلامت کامل محیط و آمادگی برای فصل بعد، این چهار استعلام ساده را در ترمینال پروژه اجرا کن:

git --version
git status
git config --get user.name
git config --get user.email

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

در فصل قبل مخزن خالی Git را ساختیم، اما هنوز هیچ ثبت تاریخی صورت نگرفته است. در این درس، اولین عکس لحظه‌ای Snapshot واقعی پروژه سفر سیمرغ را خلق می‌کنیم.

برای دنبال کردن تغییرها، سه چیز را از هم جدا کن: Working Tree فایل‌های روی دیسک است؛ Index / Staging Area نسخه انتخاب‌شده برای commit بعدی؛ و Repository محل نگهداری اشیای تاریخچه در مخزن است.

HEAD نام دیتابیس یا منطقه ذخیره‌سازی نیست؛ مرجع موقعیت فعلی توست که معمولاً شاخه فعال را دنبال می‌کند. پس از اولین commit، عبارت «مقایسه با HEAD» یعنی مقایسه با snapshot کامیت فعلی. پیش از اولین commit هنوز چنین snapshotی وجود ندارد.

پیش از آنکه نخستین کامیت را ثبت کنیم، وضعیت فعلی ترمینال را در پوشه simorgh-journey بررسی می‌کنیم:

git status --short

اکنون وقت آن است که فایل اصلی پروژه را برای ثبت در کامیت بعدی آماده Stage کنیم. با اجرای دستور زیر، نسخه فعلی فایل وارد Index می‌شود:

git add index.html
git status --short

برای تمرین کار با چند فایل، یک فایل استایل ساده می‌سازیم. در VS Code فایلی به نام style.css بساز و متن زیر را در آن ذخیره کن:

body { font-family: Tahoma, sans-serif; }

git add style.css
git status --short

برای درک عمیق رفتار Index، این آزمایش عملی را انجام بده: به انتهای فایل style.css خط زیر را اضافه و ذخیره کن (اما فعلاً دستور git add را مجدداً اجرا نکن):

h1 { letter-spacing: 0.02em; }

git status --short

برای اینکه هر دو خط فایل style.css در کامیت نخست قرار گیرند، دستور git add را مجدداً روی این فایل اجرا می‌کنیم:

git add style.css
git status --short

حالا وقت آن است که پیش‌نویس موجود در Index را به عنوان اولین نقطه ثبت رسمی تاریخچه Commit ذخیره کنیم:

git commit -m "Create initial journey website"

git status --short

پس از ثبت نخستین کامیت، باید از یکسان بودن نام شاخه اصلی پروژه با استانداردهای مدرن صنعت نرم‌افزار (مانند GitHub و GitLab) مطمئن شویم. سیستم‌های قدیمی گیت ممکن است نام پیش‌فرض را master بگذارند، اما در این دوره نام انتخابی مشترک main است.

اشاره‌گر HEAD مثل سنجاق «شما اینجا هستید» روی نقشه است که نشان می‌دهد هم‌اکنون کدام کامیت و شاخه در پوشه کاری شما فعال است. همچنین هر کامیت یک شناسه اختصاصی ۴۰ کاراکتری SHA-1 Hash دریافت می‌کند که نمایش کوتاهش معمولاً حداقل ۷ کاراکتر است؛ طول نمایش کوتاه و الگوریتم هش می‌تواند متفاوت باشد.

git branch -M main
git log -1 --oneline

اگر برنامه‌نویسی فایلی را ویرایش کند، git add را بزند و سپس خط دیگری به همان فایل اضافه کند اما دوباره Stage نکند؛ هنگام اجرای git commit کدام نسخه ثبت می‌شود و خط دوم چه سرنوشتی دارد؟

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

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

پیش از آنکه فایل‌ها را به Staging Area / Index بفرستیم، باید نحوه نگاه گیت به تغییرات پوشه کاری Working Tree را بشناسیم:

در نرم‌افزار VS Code فایل index.html را باز کن و خط زیر را پیدا کن:

Status: The caravan has a digital scribe.

همین متن را دقیقاً با جمله جدید زیر جایگزین و فایل را ذخیره کن:

Status: The caravan has started the journey.

git status --short

پیش از Stage کردن، همیشه خروجی زنده پروژه را بررسی می‌کنیم:

در ریشه پوشه پروژه simorgh-journey فایل جدیدی به نام journey-log.txt بساز و متن زیر را در آن ذخیره کن:

Takeoff confirmed. The caravan has entered the Valley of Quest.

git status --short

وقتی چند فایل مرتبط دارید، به جای وارد کردن تک‌تک اسامی، می‌توانی از کاراکتر نقطه (.) استفاده کنی. نقطه در ترمینال به معنای «پوشه جاری و تمام زیرپوشه‌های آن» است:

git add .
git status --short

پیش از اجرای کامیت، برنامه‌نویسان حرفه‌ای همواره خلاصه محتوای موجود در Index را با دستور git diff --staged بازبینی می‌کنند:

git diff --staged --stat

حالا پیش‌نویس آماده‌شده را با یک پیام شفاف و انگلیسی کامیت می‌کنیم:

git commit -m "Record caravan takeoff"

git status --short

برای مشاهده تاریخچه ثبت‌شده و اطمینان از ترتیب زمانی کامیت‌ها، دستور زیر را اجرا کن:

git log -2 --oneline

فرض کن در پوشه پروژه ۳ فایل تغییر کرده‌اند: دو فایل مربوط به مأموریت جدید و یک فایل شامل کلمه عبور شخصی یا فایل موقت (.env). چرا استفاده مستقیم از git add . در این شرایط یک خطای بزرگ مهندسی است؟

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

عطار در حکایت شبلی، طلب را حرکتی پیوسته می‌بیند؛ جست‌وجوگر راه حتی برای لحظه‌ای از توجه به مسیر دست نمی‌کشد. در این گام یک میانبر کاربردی به نام git commit -am را می‌آزمایی و پیش از استفاده می‌فهمی چه فایل‌هایی را وارد Commit می‌کند و چه فایل‌هایی را کنار می‌گذارد.

فرمان git commit -am ترکیب دو پرچم پرکاربرد است:

در فایل index.html وضعیت فعلی را پیدا کن:

Status: The caravan has started the journey.

آن را با متن زیر جایگزین و فایل را ذخیره کن:

Status: The caravan is crossing the Valley of Quest.

حالا استعلام وضعیت کوتاه‌نوشت را بگیرید:

git status --short

فایل index.html با علامت قرمز M دیده می‌شود (Modified). حالا میانبر را اجرا کن:

git commit -am "Update journey status for Valley of Quest"

اکنون یک فایل جدید در ریشه پروژه بساز تا رفتار میانبر را روی فایل‌های پیگیری‌نشده Untracked بیازمایی.

فایل تازه supplies.txt را بساز و متن زیر را در آن ذخیره کن:

Water and bread supplies checked.

استعلام وضعیت بگیرید تا علامت ?? را ببینی:

git status --short

اکنون عمداً تلاش کن این فایل تازه را با میانبر ثبت کنی:

git commit -am "Record travel supplies"

گزینه -a صرفاً پرونده‌هایی را که قبلاً شناسنامه Tracked گرفته‌اند اسکن می‌کند. برای این که یک فایل تازه وارد این چرخه شود، باید حداقل یک‌بار به صورت صریح با فرمان git add به گیت معرفی گردد.

برای حل این مشکل، فایل تازه را به روش صریح دو مرحله‌ای آماده‌سازی و ثبت کن:

git add supplies.txt
git status --short
git commit -m "Record travel supplies"

بررسی کن:

سناریویی را تصور کن که در آن هم‌زمان دو فایل index.html و style.css را دستکاری کرده‌ای و هر دو در وضعیت Modified هستند.

اگر کار شما روی index.html تمام شده باشد اما استایل‌ها هنوز نیمی کاره باشند، اجرای ناآگاهانه میانبر زیر چه خطری دارد؟

git commit -am "Fix index html text"

اگر دو فایل تغییریافته Tracked و یک فایل جدید Untracked در پروژه داشته باشیم و فرمان git commit -am اجرا شود، چه اتفاقی می‌افتد؟

اکنون Repository شما دارای چند نقطه ثبت شده واقعی است. در درس بعدی مسیر طی‌شده را با استعلام لاگ git log پیمایش و جزییات یک Commit را بررسی خواهیم کرد.

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

عطار می‌گوید فهم رنج راه با نگاه‌کردن به عقبه‌هایی ممکن می‌شود که مسافر یکی‌یکی پشت سر گذاشته است. تاریخچه گیت هم راه پیموده‌شده پروژه را به ترتیب Snapshotهای ثبت‌شده نشان می‌دهد. در این درس با ابزارهای git log و git show تاریخچه را رمزگشایی می‌کنیم.

هر Commit در دیتابیس گیت یک شیء مستقل و تغییرناپذیر است که از چهار بخش اصلی تشکیل می‌شود:

برای دیدن تمام ثبت‌های پروژه از جدیدترین به قدیمی‌ترین در یک نمای تک‌خطی و فشرده، دستور زیر را اجرا کن:

git log --oneline --decorate

اگر بخواهی جزییات کامل و شناسنامه تازه‌ترین Commit را مشاهده کنی، از پرچم محدودکننده -1 استفاده کن:

git log -1

خروجی را بررسی کن: کد هش ۴۰ کاراکتری، نام نویسنده، تاریخ کامل و متن پیام نمایش داده می‌شوند.

برای مشاهده ساختار درختی و پیوندهای میان Commitها، نمای گرافی لاگ را اجرا کن:

git log --oneline --graph --decorate --all

چون تا این لحظه شاخه فرعی نساخته‌ایم، یک خط مستقیم متصل را می‌بینی که تمام نقاط ثبت‌شده را به ترتیب زمانی نشان می‌دهد و آخرین نقطه با برچسب HEAD -> main علامت خورده است.

در پروژه‌های بزرگ با هزاران ثبت، دیدن کل لاگ کارآمد نیست. با پرچم -n می‌توانی تعداد سطرها را محدود کنی:

git log --oneline --decorate -n 3

اکنون تنها ۳ کامیت اخیر نمایش داده شده و کامیت‌های قدیمی‌تر پنهان می‌شوند. این پرچم چیزی را پاک نمی‌کند، فقط نمای نمایش را محدود می‌سازد.

برای بررسی روند سفر از نقطه آغاز تا به امروز، ترتیب نمایش لاگ را معکوس کن:

git log --oneline --reverse

نخستین کامیت پروژه با پیام Create initial journey website در سطر اول ظاهر می‌شود. هش کوتاه ۷ کاراکتری آن را کپی کن؛ در گام بعدی با آن کار داریم.

عبارت COMMIT_HASH جای‌نگهدار است. پیش از اجرا، آن را با شناسه واقعی اولین commit که در قدم قبل یادداشت کردی جایگزین کن؛ خود کلمه COMMIT_HASH نام یک commit نیست.

برای باز کردن یک Commit مشخص و مشاهده کدها و تغییرات دقیق آن، از فرمان git show استفاده کن:

git show COMMIT_HASH
git show --stat COMMIT_HASH

هدهد می‌خواهد اول کامیت درست را پیدا کند و بعد تغییرهای همان کامیت را ببیند. در یک یا دو جمله توضیح بده git log و git show چه نقش متفاوتی در این مسیر دارند.

پیش از ترک وادی طلب، وضعیت کلی پروژه و ثبت‌های اخیر را یک‌جا کنترل کن:

git status --short
git log --oneline --decorate -n 4

کاروان از وادی طلب گذشته و به سرزمینی رسیده است که هر تصمیم در آن با شور و شتاب همراه می‌شود. هدهد از کاتب می‌خواهد پیش از ثبت هر خبر، آن را در آینه دقیق ببیند؛ چرا که هیجانِ تغییر می‌تواند یک اشتباه کوچک را هم وارد تاریخچه پروژه کند.

عطار وادی عشق را با آتشی آغاز می‌کند که مسافر را بی‌تفاوت نمی‌گذارد. در پروژه نرم‌افزاری هم تغییر لازم است، اما مهندس واقعی پیش از اجرای Commit چشمانش را به تفاوت نسخه‌ها می‌دوزد. در این مأموریت با ابزار git diff یاد می‌گیریم چطور تغییرات پوشه کاری Working Tree را خط‌به‌خط بخوانیم.

فرمان git diff بدون پرچم اضافی، پوشه کاری Working Tree را با محیط آماده‌سازی Index / Staging Area مقایسه می‌کند:

در نرم‌افزار VS Code فایل index.html را باز کن و خط زیر را پیدا کن:

Status: The caravan is crossing the Valley of Quest.

همین متن را دقیقاً با جمله جدید زیر جایگزین و فایل را ذخیره کن:

Status: The caravan has entered the Valley of Love.

صفحه را در مرورگر وب Refresh کن. با دیدن وضعیت تازه مطمئن می‌شوی تغییر روی دیسک در پوشه کاری Working Tree درست ذخیره شده است.

محتوای فعلی فایل journey-log.txt را با گزارش ساختاریافته زیر جایگزین و ذخیره کن:

SIMORGH JOURNEY LOG
Departure: Confirmed
Guide: Hudhud
Destination: Mount Qaf
Map: Draft
Current valley: Love
Weather: Clear
Water: Checked
Bread: Checked
Camp: Ready
Watch: Active
Formation: Stable
Supplies: Checked
Song: Draft
Next checkpoint: Unknown

وضعیت فشرده ترمینال را بررسی کن:

git status --short

برای دیدن تغییرات خط‌به‌خط، فرمان زیر را اجرا کن:

git diff

به خطوط قرمز با علامت - و خطوط سبز با علامت + توجه کن. بخش‌های با علامت @@ همان Hunk یا تکه تغییرات هستند.

وقتی چند فایل تغییر کرده‌اند، می‌توانی با اضافه کردن جداکننده -- و نام فایل، فقط تغییرات همان فایل را ایزوله کنی:

git diff -- index.html

علامت -- به گیت می‌گوید عبارت بعدی نام مسیر فایل است، نه نام شاخه Branch یا Commit.

برای دیدن آمار خلاصه‌شده تغییرات بدون نمایش متن کامل کدها، از پرچم --stat استفاده کن:

git diff --stat

کاتب فایل تازه‌ای ساخته و در git status --short آن را با علامت ?? می‌بیند، اما git diff هیچ متنی برای آن نشان نمی‌دهد. چرا؟

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

عطار بی‌قراری ماهی برای بازگشت به جای خود را چنین تصویر می‌کند. تغییرهای پروژه نیز ممکن است در Working Tree یا Index قرار داشته باشند. در این درس با سه مقایسه جای دقیق هر تغییر را پیدا می‌کنی و دو اصلاح مستقل در یک فایل را به دو Commit منسجم و شفاف تقسیم می‌نمایی.

برای آن که بدانی کدها در چه مرحله‌ای از چرخه گیت هستند، سه دستور اصلی مقایسه وجود دارد:

گاهی در طول یک روز کاری، چند بخش مختلف از یک فایل را دستکاری می‌کنی (مثلاً هم یک باگ را برطرف می‌کنی و هم استایل جدید می‌نویسی). آیا باید همه را در یک کامیت آشفته ثبت کنی؟

از دو فایل تغییرکرده، فعلاً فقط فایل index.html را Stage کن و دو مقایسه را پشت سر هم ببین:

git add index.html
git diff -- index.html
git diff --staged -- index.html

حالا مرزها را در مقیاس کل پروژه و به صورت خلاصه‌شده مقایسه کن:

git diff --stat
git diff --staged --stat
git diff HEAD --stat

دستور اول فقط journey-log.txt را نشان می‌دهد (غیرآماده)، دستور دوم فقط index.html را (آماده) و دستور سوم هر دو فایل را به طور هم‌زمان نمایش می‌دهد.

پس از Stage شدن index.html و Stage نشدن journey-log.txt، چرا git diff فقط گزارش سفر را نشان می‌دهد ولی git diff HEAD هر دو فایل را می‌بیند؟

گزارش سفر را هم Stage کن، عکس کامل آماده‌شده را بازبینی کرده و ثبت کن:

git add journey-log.txt
git diff --staged --stat
git commit -m "Record arrival in Valley of Love"
git status --short

در فایل journey-log.txt دو جای مختلف و دور از هم را ویرایش کن:

۱. خط Map: Draft را به Map: Reviewed تغییر بده.

۲. خط Song: Draft را به Song: Final تغییر بده و فایل را ذخیره کن.

سپس تفاوت متنی را مشاهده کن:

git diff -- journey-log.txt

فاصله میان این دو خط باعث می‌شود گیت آن‌ها را به عنوان دو تکه Hunk مجزا شناسایی کند. این دو تغییر به دو هدف مستقل تعلق دارند.

برای اینکه تنظیمات شخصی نمایش diff دو تکه دور از هم را یکی نکند، در همین فرمان فاصله نمایشی را مشخص می‌کنیم؛ این گزینه‌های -c تنظیمات دائمی تو را تغییر نمی‌دهند.

حالا حالت تعاملی پچ را برای این فایل فعال کن:

git -c diff.context=3 -c diff.interHunkContext=0 add -p journey-log.txt

محتوای دو سوی فایل را جداگانه بازبینی کن:

git diff --staged -- journey-log.txt
git diff -- journey-log.txt

دستور اول فقط تغییر Map را در Index نشان می‌دهد و دستور دوم تغییر Song را در Working Tree می‌بیند. حالا کامیت اول را ثبت کن:

git commit -m "Review caravan map"

سپس تغییر باقی‌مانده را Stage کرده و کامیت دوم را بساز:

git add journey-log.txt
git commit -m "Finalize caravan song"
git status --short

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

عطار ظاهر زیبا و آرزوی پنهان طوطی را کنار هم می‌آورد. این حکایت در پروژه یادآور فایل‌های محلی و تنظیمات شخصی است؛ فایل‌هایی که وجودشان روی رایانه شما لازم است، اما نباید وارد دیتابیس عمومی Repository شوند.

فایل .gitignore متنی شامل الگوهای متنی Ignore Pattern است که نحوه تعامل گیت با فایل‌های نادیده‌گرفته‌شده را مشخص می‌کند:

در ریشه پروژه فایل .env.local را بساز و مقدار نمایشی زیر را در آن ذخیره کن:

API_TOKEN=demo-only-do-not-use

فایل دوم را با نام cache.tmp بساز و متن زیر را قرار بده:

local preview cache

پیش از تعریف قوانین پنهان‌سازی، استعلام وضعیت ترمینال را بررسی کن:

git status --short

در ریشه پوشه پروژه فایلی به نام .gitignore بساز و این دو الگو را در آن ذخیره کن:

.env.local
*.tmp

گزارش وضعیت و دلیل دقیق پنهان شدن فایل‌ها را با ابزار git check-ignore عیب‌یابی کن:

git status --short
git check-ignore -v .env.local cache.tmp

در خروجی دستور اول، فقط خود فایل .gitignore با علامت ?? دیده می‌شود. خروجی دستور دوم نام فایل قوانین، شماره خط و الگوی دقیق نادیده‌گرفته‌شدن هر فایل را نشان می‌دهد.

این خط جدید را به انتهای فایل .gitignore اضافه کن:

/temp/

سپس در ریشه پروژه پوشه‌ای به نام temp بساز و فایلی به نام route.txt داخل آن ایجاد کن:

git check-ignore -v temp/route.txt

حالا با خیال راحت دستور انتخاب همه‌جانبه را اجرا کرده و ورود فایل‌ها را بررسی کن:

git status --short
git add .
git status --short

فایل config.env قبلاً کامیت شده و اکنون نامش به .gitignore اضافه شده است. چرا گیت هنوز تغییرات آن را ردیابی می‌کند و برای یک راز واقعی چه کارهایی لازم است؟

محتوای آماده‌شده فایل قوانین را بازبینی و در یک Commit ثبت کن:

git diff --staged -- .gitignore
git commit -m "Add ignore rules for local files"
git status --short

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

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

دستور git restore PATH دارای دو جهت مشخص در معماری گیت است:

اگر فایلی هنوز Stage نشده باشد، محتوای Index با آخرین کامیت HEAD یکسان است؛ در نتیجه بازیابی، فایل را به حالت آخرین Commit برمی‌گرداند.

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

Status: The caravan has entered the Valley of Love.

عبارت بالا را با پیام اشتباه زیر جایگزین کرده و فایل را ذخیره کن:

Status: ROUTE DATA LOST.

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

git status --short
git diff -- index.html

هیچ تغییری Stage نشده و محتوای Index با HEAD یکسان است.

اگر اکنون دستور git restore index.html اجرا شود، کدام نسخه وارد Working Tree می‌شود و چه بلایی سر پیام اشتباه می‌آید؟

پس از اطمینان از اشتباه‌بودن تغییر، با دستور زیر فایل را به حالت سالم Index بازگردان:

git restore index.html
git status --short

دستور git restore تنها برای لغو ویرایش خطوط نیست؛ اگر فایلی که در گیت Tracked است به طور کامل از روی دیسک حذف شود نیز می‌توان آن را بازسازی کرد.

فایل style.css را از پنل فایل‌های VS Code یا ترمینال حذف کن، سپس وضعیت را استعلام کرده و آن را بازیابی کن:

git status --short
git restore style.css
git status --short

وقتی در چندین فایل تغییرات آزمایشی ایجاد کرده‌ای، می‌توانی همه آن‌ها را یکجا با پرچم نقطه . لغو کنی.

در journey-log.txt عبارت Weather: Clear را به Weather: Storm تغییر بده و کل محتوای supplies.txt را با عبارت زیر جایگزین کن:

Supplies unavailable.

git diff --stat
git restore .
git status --short

فرض کن فایلی جدید به نام draft.txt در پروژه ساخته‌ای که هنوز Untracked است و هرگز به گیت معرفی نشده است.

در واپسین منزل وادی عشق، کاتب مقصد بعدی کاروان را روی گزارش نوشت و پیش از بازبینی نهایی، برگه را روی میز آماده‌سازی گذاشت. نوشته کاملاً درست بود؛ فقط هنوز زمان ثبت رسمی‌اش نرسیده بود.

این بار قرار نیست نوشته روی برگه را پاک کنیم. هدف این است که برگه را از روی میز آماده‌سازی Staging Area برداریم، محتوا را روی دیسک Working Tree نگه داریم و پس از بازبینی کامل درباره Commit تصمیم بگیریم.

فرمان git restore بر اساس پرچم ورودی، دو مقصد کاملاً متفاوت در معماری گیت دارد:

در گذشته دستور git reset HEAD PATH برای این کار استفاده می‌شد، اما معرفی پرچم --staged در دستور جدید git restore قصد دقیق مهندس را شفاف‌تر نشان می‌دهد.

ابتدا تغییر واقعی مقصد کاروان را در گزارش سفر ایجاد می‌کنیم.

Next checkpoint: Unknown

سطر بالا را با عبارت مقصد وادی بعدی جایگزین کرده و فایل را ذخیره کن:

Next checkpoint: Valley of Knowledge

فایل را به محیط آماده‌سازی اضافه کن و وضعیت Stage آن را بررسی نما:

git add journey-log.txt
git status --short
git diff --staged -- journey-log.txt

فرض کن تصمیم گرفته‌ای این تغییر هنوز وارد کامیت نشود. فقط انتخاب Stage را پس بگیر:

git restore --staged journey-log.txt

پشت صحنه چه اتفاقی افتاد؟ Git نسخه journey-log.txt موجود در Index را از آخرین کامیت HEAD بازسازی کرد. اما فایل روی دیسک در Working Tree دست‌نخورده باقی ماند.

برای اینکه با چشمان خودت ببینی نوشته روی دیسک باقی مانده، هر دو سوی تغییر را استعلام کن:

git status --short
git diff --staged -- journey-log.txt
git diff -- journey-log.txt

فرق حیاتی git restore journey-log.txt با git restore --staged journey-log.txt چیست و کدام‌یک می‌تواند نوشته روی دیسک را از بین ببرد؟

وقتی چندین فایل را اشتباهاً Stage کرده‌ای، می‌توانی همه آن‌ها را یکجا با پرچم نقطه . Unstage کنی.

در فایل supplies.txt سطر فعلی را موقتاً با متن زیر جایگزین کن:

Water and bread supplies packed too early.

git add journey-log.txt supplies.txt
git restore --staged .
git status --short

اکنون تغییر موقت آذوقه را از دیسک پاک کن، اما تغییر مقصد واقعی را Stage و کامیت کن:

git restore supplies.txt
git add journey-log.txt
git diff --staged -- journey-log.txt
git commit -m "Set next checkpoint to Valley of Knowledge"

پیش از پایان فصل سوم، صحت شاخه، وضعیت پوشه کاری و آخرین کامیت‌های پروژه را استعلام کن:

git branch --show-current
git status --short
git log --oneline --decorate -n 5

وادی عشق را با موفقیت پشت سر گذاشتی! اکنون می‌دانی چطور تغییرات را دقیق پیش از ثبت بخوانی، فایل‌های محلی را نادیده بگیری و تغییرات Staging Area را پس بگیری.

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

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

پیش از بازکردن راه تازه و شاخه‌بندی، ابتدا وضعیت فعلی پروژه، شاخه فعال و سه کامیت اخیر را استعلام کن:

git branch --show-current
git status --short
git log --oneline --decorate -n 3

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

ساختن Branch جدید، اشاره‌گر HEAD را به‌طور خودکار جابه‌جا نمی‌کند؛ ساخت شاخه و جابه‌جایی به آن دو دستور کاملاً مستقل هستند.

برای مأموریت آماده‌سازی فهرست پرندگان، یک شاخه جدید به نام feature/bird-roster بساز:

git branch feature/bird-roster

در گیت، سکوت ترمینال پس از اجرای دستور یعنی عملیات با موفقیت انجام شده است.

فهرست شاخه‌های موجود و شناسه کامیتی که هر کدام به آن اشاره دارند را با پرچم جزئیات ببین:

git branch -v

نام شاخه فعال فعلی را بدون اطلاعات اضافی بخوان:

git branch --show-current

خروجی هنوز main است.

کاتب شاخه feature/bird-roster را ساخته، اما هنوز روی شاخه main ایستاده است.

اگر همین حالا فایلی را تغییر داده و Commit کند، کدام Branch به جلو حرکت می‌کند و چرا؟

اکنون وقت آن است که با دستور switch به شاخه مأموریت منتقل شوی:

git switch feature/bird-roster

پیام گیت جابه‌جایی به شاخه را تأیید می‌کند: Switched to branch 'feature/bird-roster'

موقعیت جدید خود را با دو دستور مکمل بررسی کن:

git branch --show-current
git log -1 --oneline --decorate

هدهد کاروان را به دو گروه تقسیم می‌کند. بلبل و طوطی باید فهرست همراهان را بنویسند و شاهین باید یادداشت‌های مسیر را آماده کند؛ هر گروه مسئول یک خروجی روشن است.

عطار می‌گوید سیر هر کس با اندازه و حال خودش پیوند دارد. در پروژه نرم‌افزاری هم Branchها زمانی مفیدند که هرکدام مأموریتی مشخص داشته باشند، نه اینکه بی‌هدف زیاد شوند.

دستور git switch TARGET_BRANCH شاخه‌ای را که HEAD دنبال می‌کند تغییر می‌دهد. گیت هنگام جابه‌جایی، لایه‌های خود را هماهنگ می‌سازد:

روی شاخه feature/bird-roster فایلی به نام bird-roster.txt بساز و دقیقاً محتوای زیر را در آن قرار بده:

CARAVAN BIRD ROSTER
Hudhud - Guide
Nightingale - Singer
Parrot - Keeper
Falcon - Scout

git status --short

فهرست ساخته‌شده را Stage کرده، صحت تغییر را بررسی کن و نخستین کامیت این شاخه را ثبت نما:

git add bird-roster.txt
git diff --staged -- bird-roster.txt
git commit -m "Add caravan bird roster"

تاریخچه همه شاخه‌ها را به صورت نمودار گرافیکی در ترمینال ببین:

git log --oneline --graph --decorate --all -n 5

اکنون به شاخه اصلی پروژه برگرد و وضعیت فایل‌ها روی دیسک را کنترل کن:

git switch main
git status --short

به پوشه پروژه نگاه کن؛ فایل bird-roster.txt دیگر دیده نمی‌شود!

برای رفت و برگشت سریع بین دو شاخه اخیر، از پرچم dash (-) استفاده کن:

git switch -
git branch --show-current
git switch main

وقتی روی شاخه مأموریت برمی‌گردی، فایل bird-roster.txt بلافاصله روی دیسک ظاهر می‌شود.

برای گروه دوم (یادداشت‌های مسیر)، شاخه جدیدی بساز و در همان لحظه وارد آن شو:

git switch -c feature/route-notes

گزینه -c (مخفف create) ابتدا شاخه جدید را از کامیت فعلی می‌سازد و سپس HEAD را به آن منتقل می‌کند.

فایل route-notes.txt را با محتوای زیر بساز و مأموریت گروه دوم را کامیت کن:

ROUTE NOTES
Northern pass: Open
Water stop: Marked
Night camp: Ready

git add route-notes.txt
git commit -m "Add route notes"

یکی از هم‌تیمی‌ها می‌گوید: «اگر Working Tree تمیز نباشد، Git همیشه اجازه switch نمی‌دهد.»

این جمله چه ایرادی دارد و تصمیم امن پیش از جابه‌جایی چیست؟

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

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

در اجرای دستور git merge SOURCE_BRANCH، شاخه‌ای که روی آن ایستاده‌ای مقصد ادغام است. همیشه جهت حرکت را مشخص کن:

ابتدا به شاخه اصلی برگرد و شاخه فهرست پرندگان را به صورت مستقیم ادغام کن:

git switch main
git merge --ff-only feature/bird-roster

خروجی ترمینال عبارت Fast-forward را نشان می‌دهد.

تاریخچه کامیت‌ها و وضعیت پوشه کاری را بررسی کن:

git log --oneline --graph --decorate --all -n 6
git status --short

حالا شاخه یادداشت‌های مسیر را از سمت همین main ادغام کن:

git merge --no-edit feature/route-notes

این بار main کامیت فهرست را دارد و feature/route-notes کامیت مسیر را؛ هیچ‌کدام جد مستقیم دیگری نیستند.

شکل تاریخچه و کالبدشناسی کامیت ادغام را بررسی کن:

git log --oneline --graph --decorate --all -n 8
git show --no-patch --pretty=raw HEAD

هر دو بار دستور git merge را روی شاخه main اجرا کردی.

چرا ادغام نخست Fast-forward بود، اما ادغام دوم یک Merge Commit ساخت؟

فهرست شاخه‌هایی که کامیت‌های آن‌ها وارد تاریخچه main شده است را بررسی کن:

git branch --merged

هر دو شاخه مأموریت باید در این لیست دیده شوند.

اشاره‌گرهای شاخه‌های تمام‌شده را با روش حذف امن پاک کن:

git branch -d feature/bird-roster feature/route-notes

فهرست نهایی شاخه‌ها و وضعیت پوشه کاری را بررسی نما:

git branch -v
git status --short

پس از بازگشت دو گروه، درباره آرایش شبانه کاروان اختلافی پیش می‌آید. بلبل می‌خواهد خط آواز را هدایت کند و شاهین می‌خواهد خط دیده‌بانی را؛ هر دو پیشنهاد درست‌اند، اما کاتب هرکدام را جداگانه روی همان خط از فایل گزارش ثبت می‌کند.

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

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

از شاخه اصلی main یک شاخه جدید برای پیشنهاد بلبل بساز و شاخه فعال را تأیید کن:

git switch -c feature/nightingale-route
git branch --show-current

خروجی فرمان دوم باید feature/nightingale-route باشد.

در فایل journey-log.txt سطر زیر را پیدا کن:

Formation: Stable

فقط همان سطر را با پیشنهاد بلبل جایگزین کن:

Formation: Nightingale leads the song line

git diff -- journey-log.txt
git commit -am "Let Nightingale lead the formation"

به شاخه اصلی main برگرد. در این Snapshot سطر آرایش هنوز نسخه قدیمی Formation: Stable است:

git switch main

همان سطر را این بار با پیشنهاد شاهین جایگزین کرده و کامیت کن:

Formation: Falcon leads the scouting line

git commit -am "Let Falcon lead the formation"

پیش از اجرای ادغام، انشعاب متعارض دو شاخه را در گراف تاریخچه ببین:

git log --oneline --graph --decorate --all -n 7

پیشنهاد بلبل را از سمت شاخه main ادغام کن تا بروز تعارض را تجربه کنی:

git merge feature/nightingale-route
git status --short

این بلوک نمونه خروجی Git است، نه متنی برای افزودن به فایل. اگر نمایش تعارض diff3 فعال باشد، یک بخش مبنای مشترک با نشانگر ||||||| هم می‌بینی؛ در حل نهایی همه نشانگرها و نسخه‌های رقیب را با سطر ترکیبی قدم بعد جایگزین کن.

فایل journey-log.txt را در VS Code باز کن. گیت دو روایت را میان نشانگرهای سه‌گانه زیر محصور کرده است:

<<<<<<< HEAD
Formation: Falcon leads the scouting line
=======
Formation: Nightingale leads the song line
>>>>>>> feature/nightingale-route

گیت هر دو متن را می‌بیند. چرا نمی‌تواند خودش تشخیص دهد کدام جمله درست‌تر است و وضعیت مخزن تا پیش از حل چه معنایی دارد؟

تمام بلوک نشانگرها و دو جمله رقیب را پاک کن و فقط ترکیب هوشمندانه زیر را به جای آن‌ها بنویس:

Formation: Nightingale sings while Falcon scouts

git diff --check
git add journey-log.txt
git diff --staged -- journey-log.txt

نتیجه حل‌شده را کامیت کن و شاخه فرعی تمام‌شده را پاک کن:

git commit -m "Resolve formation route conflict"
git branch -d feature/nightingale-route
git status --short
git log --oneline --graph --decorate -n 7

نشان «راهبر مسیرهای موازی» را به دست آوردی! اکنون شاخه‌ها و HEAD را دقیق می‌شناسی، مسیرهای مستقل می‌سازی، دو شکل Merge را تشخیص می‌دهی و Conflict را با خواندن نشانگرها حل می‌کنی.

طوطی هنوز گزارش مسیر را کامل نکرده که پیامی فوری از گروه آذوقه می‌رسد. گزارش نیمه‌تمام برای Commit آماده نیست، اما تغییر فوری هم نمی‌تواند منتظر بماند؛ پاک‌کردن نوشته یا ثبت یک Commit ناقص هر دو انتخاب‌های اشتباهی هستند.

کاروان وارد وادی استغنا شده است؛ جایی که بادِ عطار نظم آشنای یک سرزمین را در یک دم برهم می‌زند. مسئله این درس هم مدیریت همین وقفه است: کار نیمه‌تمام را موقتاً در کشوی مخفی کنار می‌گذاری تا مسیر اصلی برای مأموریت فوری تمیز شود.

فرمان git stash دقیقاً برای چنین وقفه‌هایی طراحی شده است. این ابزار تغییرهای Staged و Unstaged شما را موقتاً در پشته‌ای صفی‌مانند ذخیره کرده، Working Tree را به وضعیت تمیز آخرین Commit برمی‌گرداند و اجازه می‌دهد پس از انجام کار فوری، به همان نوشته‌های نیمه‌کاره بازگردید.

دستور git stash به‌صورت پیش‌فرض تغییرات فایل‌های Tracked (فایل‌های ردیابی‌شده در گیت) را ذخیره کرده و Working Tree را به وضعیت HEAD بازمی‌گرداند. این ذخیره یک Commit عادی روی شاخه نیست و در git log معمولی دیده نمی‌شود.

قبل از شروع تمرین، ابتدا وضعیت شاخه، تغییرات فعلی و پشته Stash را بررسی کنید تا مطمئن شوید روی یک نقطه تمیز قرار دارید:

git branch --show-current

git status --short

git stash list

در فایل route-notes.txt که از قبل ردیابی می‌شود (Tracked)، وضعیت گذرگاه شمالی را به‌صورت نیمه‌کاره تغییر دهید:

Northern pass: Open

Northern pass: Under review

git diff -- route-notes.txt

اکنون یک فایل گزارش تازه به نام scout-report.txt ایجاد کنید تا رفتار Stash را با فایل‌های ردیابی‌نشده (Untracked) آزمایش کنیم:

SCOUT REPORT
Detachment pass: Draft
Signal point: Unknown