گیت از زمین خاکی

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

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

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

اما سفر به قله قاف بس طولانی و پرخطر است. تمام اتفاقات این سفر عظیم باید توسط یک شخص امین در دفتر تاریخی کاروان ثبت شود.

🎭 نقش تاریخی تو چیست؟

تو همان «کاتب و نگهبان دفتر کاروان» هستی! تمام سخنان هدهد، تصمیم‌های پرندگان و گزارش‌های هفت وادی باید با دست‌های تو ثبت و نگاهداری شود.

🎯 مسئله

دفتر اولیه کاروان پرندگان در قالب یک فایل دیجیتال به نام index.html آماده شده است. پیش از هر چیز، باید این دفتر را در مرورگر باز کنی تا ظاهر صفحه گردهمایی پرندگان را ببینی.

⌨️ اقدام

وارد پوشه پروژه simorgh-journey شو و روی فایل index.html دوبار کلیک کن تا در مرورگر اینترنت باز شود.

✅ دستاورد

صفحه‌ای زیبا با تیتر «🪶 سفر پرندگان به سوی سیمرغ» و متن وضعیت «گردهمایی پرندگان» در مرورگر ظاهر می‌شود.

🎯 مسئله

برای اینکه بدانی دفتر سفر چگونه نوشته شده، باید کدهای ساده فایل index.html را بشناسی.

⌨️ اقدام

فایل index.html را باز کن و ساختار عمومی آن از جمله تگ <h1> (عنوان سفر) و <p> (متن وضعیت) را مشاهده کن.

✅ دستاورد

درک کامل از ساختار ساده متن و تگ‌های HTML که قرار است گزارش‌های سفر پرندگان در آن‌ها ثبت شود.

🎯 مسئله

برای ویرایش، افزودن گزارش‌های هدهد و ثبت تاریخچه، نیاز به یک نرم‌افزار حرفه‌ای داری. محیط کاری ما نرم‌افزار VS Code است.

⌨️ اقدام

نرم‌افزار VS Code را باز کن. سپس پوشه simorgh-journey را کشیده و داخل پنجره VS Code رها کن (یا از منوی File گزینه Open Folder را انتخاب کن).

✅ دستاورد

پوشه سفر در منوی سمت چپ VS Code بارگذاری شده و فایل index.html آماده ثبت گزارش است.

🎯 مسئله

کاتب کاروان برای صدور دستورات گیت نیاز به خط فرمان (ترمینال) دارد. ترمینال همان اتاق فرماندهی توست!

⌨️ اقدام

در محیط VS Code، از منوی بالایی روی Terminal کلیک کرده و New Terminal را بزن (یا کلیدهای ترکیب کدهای `Ctrl + ~` را فشار بده).

✅ دستاورد

یک کادر مشکی/تیره در پایین VS Code باز می‌شود که آماده دریافت اولین دستورات توست.

🎯 مسئله

برای تمرینِ کار با VS Code، عنوان کاتب کاروان را درون فایل index.html اضافه کن.

⌨️ اقدام

فایل index.html را در VS Code باز کن و زیر لیست پرندگان، خط زیر را تایپ کرده و دکمه Ctrl + S را بزن:

<li>کاتب کاروان (نگهبان رسمی دفتر)</li>

✅ دستاورد

صفحه مرورگر را رفرش کن تا اضافه شدن نام کاتب کاروان به لیست پرندگان را تماشا کنی!

❓ چالش تحلیلی

کاتب کاروان متن فایل index.html را در VS Code تغییر داد اما دکمه ذخیره (Save) را نزد. او سپس مرورگر را رفرش کرد. چرا تغییرات جدید در مرورگر نمایش داده نشدند؟

🎓 جمع‌بندی اولین مأموریت

آفرین بر تو ای کاتب هوشمند! ابزارهای اولیه سفر (مرورگر، VS Code و ترمینال) آماده شدند. هدهد لبخند رضایت زد. در درس بعدی ابزار قدرتمند گیت را بررسی می‌کنیم.

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

هدهد به او بانگ برآورد که:

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

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

تصور کن بلبل یا طوطی خطی از دفتر سفر را جابه‌جا کنند یا اشتباهاً گزارش روز پیش را پاک نمایند!

بدون داشتن گیت، مجبور می‌شدی ده‌ها فایل تکراری مثل index-v1.html یا index-final.html بسازی که دسکتاپت را به آشغالدانی تبدیل می‌کرد. اما Git مثل یک قطب‌نمای جادویی و حافظه تغییرناپذیر است که هر تغییر را با ثانیه و نام نویسنده‌اش دقیقاً ثبت می‌کند.

🎯 مسئله

پیش از راه افتادن کاروان، باید مطمئن شویم ابزار گیت روی رایانه تو نصب و آماده به کار است.

⌨️ اقدام

دستور زیر را در ترمینال تایپ کن و کلید Enter را بزن:

git --version

✅ دستاورد

پیامی مانند git version 2.39.0 در ترمینال ظاهر می‌شود که نشان می‌دهد ابزار گیت سالم و آماده است.

🎯 مسئله

پس از اجرای دستور نسخه، باید پیام گیت را با دقت بخوانی و بدانی در صورت عدم پاسخ چه تصمیمی بگیری.

⌨️ اقدام

پاسخ گیت در ترمینال را بررسی کن. اگر عبارتی مانند git version 2.x.x دیدی یعنی همه چیز عالی است، اما اگر با خطای command not found روبه‌رو شدی، نشان‌دهنده نصب نبودن گیت یا عدم شناسایی مسیر آن است.

✅ دستاورد

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

🎯 مسئله

کاتب پیش از صدور دستورات گیت، باید مطمئن شود ترمینال او دقیقاً در پوشه اصلی پروژه simorgh-journey قرار دارد.

⌨️ اقدام

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

pwd

✅ دستاورد

مشاهده مسیر دقیق پوشه پروژه (Print Working Directory) که تایید می‌کند در مقصد درست قرار داری.

❓ چالش عیب‌یابی

کاتب کاروان دستور git --version را در ترمینال زد، اما با خطای command not found: git مواجه شد. علت اصلی این خطا و راه برطرف کردن آن چیست؟

🎓 جمع‌بندی درس

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

سپس بلبل شیدا پیش آمد؛ با نغمه‌های آتشین. نالید که: «من عاشق گل سرخم و بی‌رخ گل یک لحظه دوام نمی‌آورم! مرا با سیمرغ چه کار؟»

هدهد پندش داد و گفت:

گل اگرچه هست بس صاحب‌جمال
حسن او در هفته‌ای گیرد زوال
عشقِ چیزی کاو زوال آرد پدید
کاملان را در نگیرد این امید

بلبل سر به زیر انداخت و خجل شد. هدهد رو به تو کرد و گفت: «ای کاتب کاروان! هر کسی که در این سفر کلامی ثبت می‌کند باید شناسنامه و نامی روشن داشته باشد. گیت باید بداند هر نوشته از دست کدام نویسنده تراوش کرده است!»

🎯 مسئله

باید نام کامل خودت را به عنوان کاتب در تنظیمات جهانی گیت ثبت کنی.

⌨️ اقدام

دستور زیر را در ترمینال وارد کن (نام خودت را بین کوتیشن بنویس):

git config --global user.name "نام و نام خانوادگی شما"

✅ دستاورد

نام تو در حافظه گیت ثبت شد تا تمام ثبت‌های آینده به نام خودت سند بخورد.

🎯 مسئله

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

⌨️ اقدام

دستور زیر را بدون وارد کردن نام در ترمینال اجرا کن:

git config user.name

✅ دستاورد

نمایش دقیق نامی که برای کاتب کاروان ثبت کرده بودی در خط بعدی ترمینال.

🎯 مسئله

علاوه بر نام، ایمیل تو نیز برای شناسایی رسمی در کارهای تیمی و گیت‌هاب ضروری است.

⌨️ اقدام

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

✅ دستاورد

نشانی ایمیل کاتب کاروان در تنظیمات گیت ضبط گردید.

🎯 مسئله

استعلام ایمیل ثبت‌شده جهت اطمینان از تایید هویت کاتب کاروان.

⌨️ اقدام

دستور زیر را در ترمینال وارد کن:

git config user.email

✅ دستاورد

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

🎯 مسئله

مشاهده تمامی تنظیمات ثبت‌شده در گیت برای اطمینان از صحت نام و ایمیل.

⌨️ اقدام

git config --list

✅ دستاورد

لیستی از مشخصات ظاهر می‌شود که شامل user.name و user.email توست.

💡 چیستی و مفهوم عمیق دستور git config

دستور git config در واقع «فایل شناسنامه و مرکز تنظیمات رفتار گیت» است. گیت یک سیستم توزیع‌شده است و هر تغییری که در پروژه ثبت می‌شود (کامیت)، مانند یک سند رسمی نیاز به امضا و آدرس نویسنده دارد.

🔑 چرا تنظیم نام و ایمیل ضروری است؟

• شفافیت در کار تیمی: اگر ۱۰ نفر روی پروژه کار کنند، مشخص می‌شود هر خط کد توسط چه کسی نوشته شده است.
• اتصال به گیت‌هاب: ایمیل ثبت‌شده در config باعث پیوند خودکار کامیت‌های سیستم شما به پروفایل گیت‌هاب‌تان می‌شود.

⚙️ لایه‌های تنظیمات (Global در برابر Local):

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

📜 استعاره داستانی: همان‌طور که کاتب کاروان مهر شخصی خود را بر موم نامه‌ها می‌فشارد، git config امضای دیجیتال شما را بر تمامی سندهای تاریخچه سفر پرندگان ثبت می‌نماید.

🎯 مسئله

تمرین تغییر نام کاتب فقط برای همین پروژه اختصاصی بدون تغییر دادن تنظیمات سراسری سیستم.

⌨️ اقدام

دستور زیر را بدون پرچم --global در ترمینال پروژه اجرا کن:

git config user.name "دبیر ارشد کاروان سیمرغ"

✅ دستاورد

ثبت نام اختصاصی برای این پروژه در فایل local گیت (.git/config).

❓ چالش سناریویی

کاتب روی یک رایانه عمومی کار می‌کند و می‌خواهد نام و ایمیل او فقط منحصر به پروژه simorgh-journey ثبت شود و سایر پروژه‌های آن سیستم تغییر نکنند. کاتب چه اقدامی باید انجام دهد؟

🎓 شناسنامه رسمی صادر شد

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

آن‌گاه باز شکاری با سر مغرور و پنجه‌های تیز پیش آمد و گفت: «من ساعد شاهان را مسکن خویش ساخته‌ام و از دست پادشاهان گوشت می‌خورم. مرا چه نیازی است که به بیابان‌های بی‌نشان بیایم و در پی سیمرغ سرگردان شوم؟»

هدهد او را پاسخ داد:

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

باز سر به زیر افکند و تسلیم شد. هدهد به تو رو کرد: «اکنون که همه پرندگان گرد آمده‌اند، دفتر simorgh-journey را بیدار کن و مخزن حافظه آن را بآفرین!»

🎯 مسئله

آزمایش پاسخ گیت در پوشه‌ای که هنوز به مخزن گیت تبدیل نشده است.

⌨️ اقدام

پیش از ساخت مخزن، دستور زیر را در ترمینال امتحان کن:

git status

✅ دستاورد

مشاهده پیام fatal: not a git repository که نشان می‌دهد این پوشه هنوز یک پوشه معمولی و بی‌حافظه است.

🎯 مسئله

پوشه simorgh-journey تاکنون یک پوشه ساده بود. باید آن را تبدیل به یک مخزن هوشمند (Repository) کنیم.

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

git init

✅ دستاورد

پیام Initialized empty Git repository صادر شده و پوشه مخفی .git در بطن پروژه متولد می‌شود.

💡 چیستی و تحلیل فنی دستور git init

دستور git init (مخفف Initialize به معنای راه‌اندازی اولیه) دستوری است که یک پوشه معمولی و ناآگاه را به یک «مخزن هوشمند گیت (Repository)» تبدیل می‌کند.

🧠 راز پوشه مخفی .git چیست؟

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

• objects/: پایگاه داده فشرده تمام فایل‌ها و نسخه کدهای شما.
• refs/: آدرس و اشاره‌گر شاخه‌ها (Branches) و تگ‌ها (Tags).
• HEAD: فایل متنی کوچکی که نشان می‌دهد هم‌اکنون روی کدام شاخه و کامیت قرار دارید.

📜 استعاره داستانی: اجرای git init مانند بیدار کردن نوری جادویی در دفتر سفر است که از این لحظه به بعد، کوچک‌ترین جنبش قلم یا تغییر صفحات را رصد و در حافظه‌ای جاودانه بایگانی می‌کند.

🎯 مسئله

تحلیل اتفاقی که پس از اجرای git init در پروژه می‌افتد و متولد شدن پوشه پنهان .git.

⌨️ اقدام

پیام ترمینال شامل عبارت Initialized empty Git repository را بخوان. پوشه .git به صورت مخفی در پروژه ساخته شده تا تمام تاریخچه را در خود نگه دارد.

✅ دستاورد

درک کامل نقش پوشه .git به عنوان مغز متفکر و پایگاه داده گیت در پروژه.

🎯 مسئله

مشاهده لیست زیرپوشه‌ها و فایل‌های درون پایگاه داده .git از طریق خط فرمان.

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

ls -la .git

✅ دستاورد

مشاهده فایل‌های کلیدی مانند HEAD، پوشه objects/ و refs/ در ترمینال.

🎯 مسئله

حالا باید از نگهبان گیت بپرسیم: «چه خبر؟ چه فایل‌هایی را در پوشه می‌بینی؟»

⌨️ اقدام

git status

✅ دستاورد

گیت با خط قرمز نشان می‌دهد که فایل index.html وجود دارد اما هنوز در ردیابی نهایی (Untracked) ثبت نشده است.

🎯 مسئله

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

⌨️ اقدام

در پنجره چپ VS Code (بخش Explorer)، به نام فایل index.html نگاه کن.

✅ دستاورد

مشاهده علامت حرف U در کنار فایل و سبز/زرد شدن رنگ آن که نشان می‌دهد VS Code نیز متوجه ردیابی‌نشدن فایل توسط گیت شده است.

💡 چیستی وضعیت Untracked (ردیابی‌نشده)

وضعیت Untracked نخستین مرحله از چرخه زندگی فایل‌ها (File Lifecycle) در گیت است.

🔍 چه اتفاقی رخ داده است؟

گیت پوشه کاری شما را اسکن کرده و می‌بیند فایلی به نام index.html وجود دارد که هنوز در دیتابیس حافظه گیت ثبت نشده است. گیت حضور فایل را حس می‌کند اما بدون اجازه صریح شما هیچ تغییری از آن را ردیابی و ذخیره نخواهد کرد.

❓ چرا گیت همه فایل‌ها را خودکار ردیابی نمی‌کند؟

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

📜 استعاره داستانی: فایل Untracked مثل مسافری تازه است که وارد کاروان شده، اما هنوز نامش در دفتر حضور و غیاب رسمی کاتب ثبت نشده است.

❓ چالش تفکر انتقادی

کاتب کاروان دستور git init را اجرا کرده و سپس عکس map.png را درون پوشه قرار می‌دهد. چرا این فایل در خروجی git status به صورت Untracked (قرمز) نمایش داده می‌شود؟

🏆 تبریک! نشان «🪶 پر هدهد» آزاد شد

با موفقیت گردهمایی پرندگان پایان یافت و دفتر سفر دارای حافظه گیت شد. تو نخستین نشان افتخار را کسب کردی! در فصل بعد گام در وادی طلب می‌گذاریم...

سرانجام کاروان پرندگان به اولین مرحله سلوک یعنی وادی طلب رسید. وادی طلب، دشتِ خواستن، جست‌وجو و رها کردن تعلّقات گذشته است.

چون فرود آیی به وادیّ طلب
پیشت آید هر زمانی صد تعب
مال و ملک و هرچه هستت واگذاری
وانگه از خود گم شوی و سر برآری

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

گیت برای ثبت هر تغییر، سه فضا یا ایستگاه مجزا دارد:

1. محیط کار تو (Working Directory): جایی که فایل‌های واقعی روی هارد دیسک قرار دارند و آن‌ها را ویرایش می‌کنی.
2. میز آماده‌سازی (Staging Area): سبد خرید مجازی تو! فایل‌هایی که کاندیدای ثبت نهایی هستند ابتدا به این فضا منتقل می‌شوند.
3. مخزن اصلی (Repository): آلبوم عکس‌های نهایی! جایی که تغییرات به صورت دائمی ثبت و شماره‌گذاری می‌شوند.

شناخت این سه ایستگاه رمز موفقیت تو در تمام پروژه‌هاست.

🎯 مسئله

باید وضعیت فعلی فایل index.html را بررسی کنیم تا ببینیم در کدام ایستگاه قرار دارد.

⌨️ اقدام

git status

✅ دستاورد

فایل با رنگ قرمز در بخش Untracked files نمایش داده می‌شود؛ یعنی فقط در Working Directory قرار دارد.

🎯 مسئله

انتقال فایل index.html از محیط کار به Staging Area (میز آماده‌سازی).

⌨️ اقدام

git add index.html

✅ دستاورد

فایل با موفقیت در صف ثبت نهایی (Staging Area) قرار گرفت.

🎯 مسئله

بررسی مجدد وضعیت فایل برای اطمینان از قرارگیری در Staging Area.

⌨️ اقدام

git status

✅ دستاورد

نام فایل به رنگ سبز و در بخش Changes to be committed دیده می‌شود.

🎯 مسئله

اگر کاتب دو فایل index.html و style.css را ویرایش کند، چگونه می‌تواند هر دو فایل مشخص را به همراه هم در ایستگاه آماده‌سازی (Staging Area) قرار دهد؟

⌨️ اقدام

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

git add index.html style.css

✅ دستاورد

با اجرای git status هر دو فایل به رنگ سبز (Changes to be committed) در ایستگاه آماده‌سازی ظاهر می‌شوند.

💡 چیستی و مفهوم دستور git add

دستور git add فایل‌های تغییریافته را از محیط کار (Working Directory) به «میز آماده‌سازی (Staging Area)» منتقل می‌کند.

🛒 چرا گیت فرآیند ثبت را دو مرحله‌ای کرده است؟

Staging Area مثل سبد خرید است! شما ممکن است ۱۰ فایل را تغییر داده باشید، اما فقط می‌خواهید ۲ تا از آن‌ها را که مربوط به یک موضوع خاص است بسته‌بندی و ثبت کنید. git add به شما قدرت انتخاب مجزا می‌دهد.

📜 استعاره داستانی: git add مثل این است که کاتب کاروان برگه‌های جدید نوشته‌شده را روی میز مجمعی بچیند تا هدهد پیش از مهر نهایی، آن‌ها را ببیند.

🎯 مسئله

ذخیره دائمی تغییرات Staging Area در Repository با یک پیام توصیفی مشخص.

⌨️ اقدام

git commit -m "ساخت دفتر سفر پرندگان"

✅ دستاورد

پیام ثبت موفقیت‌آمیز کامیت با نمایش تعداد خطوط اضافه شده صادر می‌شود.

🎯 مسئله

بررسی اوضاع پس از ثبت موفق اولین کامیت.

⌨️ اقدام

git status

✅ دستاورد

عبارت nothing to commit, working tree clean ظاهر می‌شود؛ یعنی همه‌چیز در کمال امنیت ذخیره شده است.

💡 چیستی و مفهوم عمیق دستور git commit

دستور git commit تمام محتویات موجود روی میز آماده‌سازی (Staging Area) را به صورت یک عکس لحظه‌ای غیرقابل تغییر (Snapshot) در مخزن دائمی گیت ذخیره می‌کند.

🔐 هش اختصاصی (Commit Hash) چیست؟

هر کامیت یک کد ۴۰ حرفی رمزشده (مانند a1b2c3d...) دریافت می‌کند که اثر انگشت دیجیتال آن نقطه از زمان است. این هش باعث می‌شود هیچ‌کس نتواند تاریخچه گذشته پروژه را دستکاری یا جعل کند.

📜 استعاره داستانی: git commit همان مهر زدن رسمی هدهد و صحافی محکم بر روی برگه دفتر سفر است تا برای همیشه در تاریخچه جاودانه شود.

❓ چالش تحلیلی

کاتب فایل index.html را ویرایش کرد و دستور git add index.html را زد. بلافاصله پس از آن، یک خط دیگر هم به همان فایل اضافه کرد اما مجدداً git add نزد. اگر او اکنون دستور git commit -m "تغییرات" را اجرا کند، کدام تغییرات کامیت می‌شوند؟

🎓 جمع‌بندی

بسیار عالی! اولین نقطه تاریخی کاروان ثبت شد. در صورت لزوم با دستور git branch -M main شاخه اصلی را روی main تنظیم می‌کنیم.

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

تو به عنوان دبیر باید خبر این آغاز شورانگیز را به برگه اول دفتر اضافه کنی.

🎯 مسئله

افزودن گزارش پرواز به ساختار دفتر سفر در فایل index.html.

⌨️ اقدام

این کد آماده را در فایل index.html قبل از بسته شدن تگ body اضافه کن:

<h2>🌄 آغاز سفر</h2>
<p>پرندگان به راهنمایی هدهد، سفر خود را به سوی قله قاف آغاز کردند.</p>

✅ دستاورد

گزارش جدید پرواز پرندگان در دفتر دیجیتال ثبت گردید.

🎯 مسئله

بررسی خروجی تغییرات داده شده در مرورگر اینترنت.

⌨️ اقدام

صفحه index.html بازشده در مرورگر را رفرش (Refresh) کن.

✅ دستاورد

تغییرات و تیتر «🌄 آغاز سفر» به صورت آنی در صفحه نمایان می‌شود.

🎯 مسئله

چک کردن اینکه گیت چگونه متوجه تغییرات فایل ردیابی‌شده قبلی می‌شود.

⌨️ اقدام

git status

✅ دستاورد

گیت با رنگ قرمز وضعیت فایل را تحت عنوان modified: index.html گزارش می‌دهد.

🎯 مسئله

آماده‌سازی تمامی فایل‌های ویرایش‌شده پروژه برای کامیت با یک دستور واحد.

⌨️ اقدام

git add .

✅ دستاورد

علامت نقطه‌آبی (.) تمام فایل‌های تغییر یافته در تمام پوشه‌ها را به Staging Area می‌فرستد.

🎯 مسئله

ثبت نقطه جدید سفر پرندگان در حافظه دائمی گیت.

⌨️ اقدام

git commit -m "ثبت آغاز سفر پرندگان"

✅ دستاورد

ذخیره دائمی کامیت جدید با پیام «ثبت آغاز سفر پرندگان» در مخزن.

🎯 مسئله

گاهی کاتب نیاز دارد علاوه بر عنوان کوتاه کامیت، یک خط توضیح بیشتر درون پیام کامیت قرار دهد.

⌨️ اقدام

دستور زیر را با دو پرچم -m اجرا کن:

git commit -m "docs: افزودن شعر آغاز سفر" -m "شعر منطق‌الطیر عطار نیشابوری به صفحه اضافه شد"

✅ دستاورد

کامیت جدید با یک عنوان خلاصه و یک پاراگراف توضیح مکمل در دیتابیس گیت ثبت گردید.

🎯 مسئله

اطمینان از ذخیره‌سازی کامل و تمیز بودن درخت کاری پروژه.

⌨️ اقدام

git status

✅ دستاورد

مشاهده پیام working tree clean که نشان از ثبت و امنیت کامل داده‌ها دارد.

❓ چالش سناریویی

کاتب ۱۰ فایل مختلف پروژه (شامل کادرهای قالب، اصلاح یک باگ و اضافه کردن فونت جدید) را هم‌زمان ویرایش کرده است. بر اساس استانداردهای مهندسی، کاتب باید چگونه تغییرات خود را کامیت کند؟

🎓 جمع‌بندی

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

هدهد ناگهان در پهنه آسمان دور زد و فرمان داد: «پرندگان باید بیاموزند که کارهای اضطراری و پیام‌های فوری را به سریع‌ترین شکل ممکن ثبت کنند.»

در گیت، وقتی فایلی قبلاً ردیابی (Tracked) شده باشد، می‌توانید مرحله add و commit را ترکیب کنید!

🎯 مسئله

اعمال یک تغییر سریع متنی روی فایل index.html.

⌨️ اقدام

این تغییر متنی ساده را روی تگ مربوطه در فایل اعمال کن:

<p>وضعیت سفر: حرکت به سوی وادی نخست</p>

✅ دستاورد

تغییر وضعیت در فایل ثبت شده اما هنوز کامیت نشده است.

🎯 مسئله

مرحله آماده‌سازی (add) و ثبت (commit) را هم‌زمان با یک تک‌دستور انجام بده.

⌨️ اقدام

git commit -am "به‌روزرسانی وضعیت سفر"

✅ دستاورد

ثبت کامیت بدون نیاز به اجرای مجزای `git add` انجام شد.

🎯 مسئله

تست سرعت و دقت میانبر git commit -am روی فایلی که قبلاً توسط گیت ردیابی شده است (Tracked).

⌨️ اقدام

یک تغییر کوچک در فایل index.html بده و فوراً دستور زیر را تایپ کن:

git commit -am "fix: بهینه‌سازی متن پیام هدهد"

✅ دستاورد

تغییرات بدون نیاز به اجرای مجزای git add به طور مستقیم و سریع در یک گام کامیت شدند.

🎯 مسئله

ایجاد یک فایل کاملاً جدید در پروژه برای بررسی رفتار میانبر `-am`.

⌨️ اقدام

یک فایل ساده به اسم notes.txt برای آزمایش در پوشه پروژه ایجاد کن.

✅ دستاورد

یک فایل جدید با وضعیت Untracked در پروژه پدیدار می‌شود.

🎯 مسئله

مشاهده رفتار میانبر `-am` روی فایل‌های تازه ساخت (Untracked).

⌨️ اقدام

تلاش کن دستور `git commit -am "تست فایل جدید"` را اجرا کنی.

✅ دستاورد

مشاهده اینکه گیت فایل جدید Untracked را نادیده می‌گیرد؛ زیرا این میانبر فقط برای فایل‌های از قبل ردیابی‌شده (Tracked) کار می‌کند.

💡 چیستی و شرایط میانبر git commit -am

پرچم -am ترکیبی از دو پرچم -a (All/Automatic Stage) و -m (Message) است که دو مرحله add و commit را در یک اقدام سریع ادغام می‌کند.

⚠️ شرط حیاتی استفاده از این میانبر:

این دستور فقط و فقط برای فایل‌های از قبل ردیابی‌شده (Tracked) کار می‌کند! اگر فایل جدیدی بسازید که هنوز Untracked باشد، گیت آن را با -am نادیده می‌گیرد و حتماً باید ابتدا با git add معرفی شود.

📜 استعاره داستانی: میانبر -am مثل مهر زدن فوری پیکِ آشناست که نیازی به تشریفات بازرسی مجدد ندارد.

🎯 مسئله

کامیت کردن فایل جدید notes.txt به روش استاندارد دو مرحله‌ای.

⌨️ اقدام

git add notes.txt
git commit -m "ثبت یادداشت جدید"

✅ دستاورد

فایل جدید با موفقیت به حافظه مخزن افزوده گردید.

❓ چالش عیب‌یابی

کاتب یک فایل جدید به نام secret_key.txt ساخت و بدون اجرای git add تلاش کرد با git commit -am "ذخیره تغییرات" آن را کامیت کند. چرا فایل جدید کامیت نشد؟

🎓 جمع‌بندی

مأموریت ثبت پیام فوری با موفقیت انجام شد. در درس بعد آلبوم خاطرات و تاریخچه گیت را مرور خواهیم کرد.

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

دستور git log آینه تاریخچه گیت است که تمام عکس‌ها و کامیت‌های گذشته پروژه را نشان می‌دهد.

🎯 مسئله

نمایش لیست کامل نقاط تاریخی و کامیت‌های انجام شده در ترمینال.

⌨️ اقدام

git log

✅ دستاورد

مشخصات کامل هر کامیت (نویسنده، ایمیل، تاریخ، شناسه هش) نشان داده می‌شود.

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

• commit: کد هش ۴۰ حرفی منحصربه‌فرد.
• Author: نام و ایمیل ثبت‌کننده تغییر.
• Date: زمان دقیق ثبت کامیت.
• Message: توضیحات ثبت‌شده دبیر.

🎯 مسئله

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

⌨️ اقدام

git log --oneline

✅ دستاورد

مشاهده لیستی فشرده و خوانا شامل ۷ کاراکتر اول هش کامیت به همراه پیام آن.

🎯 مسئله

رسم نمودار درختی و خطوط متصل‌کننده تاریخچه کامیت‌ها.

⌨️ اقدام

git log --graph

✅ دستاورد

نمایش نمودار گرافیکی متنی با ستاره‌ها و خطوط پیوند دهنده شاخه‌ها.

🎯 مسئله

وقتی تعداد کامیت‌های پروژه زیاد می‌شود، کاتب می‌خواهد فقط ۲ کامیت اخیر تاریخچه را مشاهده کند تا ترمینال شلوغ نشود.

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

git log --oneline -n 2

✅ دستاورد

نمایش تمیز و خلاصه فقط ۲ کامیت آخر تاریخچه در دو خط ترمینال.

💡 چیستی و کاربرد دستور git log

دستور git log «ماشین زمان و آینه تاریخچه گیت» است. این دستور تمام کامیت‌های ثبت‌شده پروژه را به ترتیب زمانی از جدیدترین به قدیمی‌ترین نمایش می‌دهد.

🛠️ پرچم‌های کاربردی git log:

• --oneline: فشرده کردن هر کامیت در یک سطر کوتاه (هش ۷ حرفی + پیام).
• --graph: رسم نمودار متنیِ شاخه‌ها و مسیرهای موازی پرواز.

📜 استعاره داستانی: git log آینه شفافی است که کاتب کاروان با نگریستن در آن، تمام ردپای پرندگان و منزلگاه‌های طی‌شده تا قله قاف را بازخوانی می‌کند.

🎯 مسئله

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

⌨️ اقدام

دستور `git log --oneline` را بزن و اولین پیام کامیت در پایین لیست را پیدا کن.

✅ دستاورد

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

❓ چالش درک ابزار

کاتب کاروان از دستور git log --oneline برای بررسی تاریخچه پروژه استفاده می‌کند. این دستور چه تفاوتی با git log معمولی دارد؟

🎓 جمع‌بندی

تبریک! وادی طلب را با موفقیت پشت سر گذاشتید و دفتر سفر پرندگان آماده ورود به وادی عشق است.

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

بعد از این وادیّ عشق آید پدید
غرق آتش شد کسی کآنجا رسید
کس در این وادی بجز آتش مباد
وانکه آتش نیست عیشش خوش مباد

📖 حکایت پروانه و شمع: پروانه‌ای از دور نور شمع را دید، اما پروانه عاشق گفت تا نزدیک نشوم و گرمای خط‌به‌خط آن را نسوزانم حقیقت را نیافته‌ام! هدهد گفت: «ای کاتب! در این وادی، تغییرات دفتر سریع و فراوان است. پیش از آنکه متنی را کامیت کنی، باید با git diff چشم بر سطرها بدوزی و تغییرات را دقیق ببینی!»

🎯 مسئله

ایجاد یک تغییر آزمایشی در فایل index.html برای مشاهده نحوه ردیابی گیت در محیط کاری.

⌨️ اقدام

فایل index.html را در VS Code باز کن و متن تگ <h2> را به عبارت زیر تغییر بده اما دستور کامیت یا اد را اجرا نکن:

<h2>🔥 ورود کاروان به وادی عشق</h2>

✅ دستاورد

تغییر در فایل ذخیره شد اما فقط در Working Directory قرار دارد و هنوز به گیت معرفی نشده است.

🎯 مسئله

مشاهده دقیق خطوطی که در محیط کار ویرایش شده‌اند پیش از انتقال به میز آماده‌سازی.

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

git diff

✅ دستاورد

گیت خط قدیمی را با علامت منفی (-) قرمز و خط جدید را با علامت مثبت (+) سبز نشان می‌دهد.

🔍 راز خروجی git diff

وقتی دستور git diff را اجرا می‌کنی، گیت دو نشانه مهم به تو می‌دهد:

• - (علامت منفی/قرمز): خطی که قبلاً بوده و اکنون پاک یا جایگزین شده است.
• + (علامت مثبت/سبز): خط جدیدی که اضافه شده است.

این مقایسه دقیقا بین Working Directory و آخرین نسخه ثبت‌شده (HEAD) انجام می‌شود.

🎯 مسئله

درک اینکه git diff تغییرات فعلی را دقیقا نسبت به چه نقطه‌ای می‌سنجد.

⌨️ اقدام

یک خط جدید به انتهای فایل اضافه کن و مجدداً git diff را اجرا کن تا هر دو تغییر را یکجا ببینی.

✅ دستاورد

دیدن تمام تفاوت‌های بین فایل روی هارد دیسک و آخرین کامیت موجود در مخزن.

🎯 مسئله

اگر کاتب چندین فایل را ویرایش کرده باشد، چگونه می‌تواند فقط تغییرات خطوط فایل اختصاصی style.css را تماشا کند؟

⌨️ اقدام

نام فایل را جلوی دستور diff در ترمینال بنویس:

git diff style.css

✅ دستاورد

نمایش تفاوت‌های خطوط قرمز (حذف‌شده) و سبز (اضافه‌شده) فقط مربوط به همان فایل مشخص.

💡 چیستی و کارکرد دستور git diff

دستور git diff به زبان ساده «میکروسکوپ مقایسه‌گر گیت» است. این دستور کدهای ویرایش‌شده در محیط کار (Working Directory) را خط‌به‌خط با آخرین کامیت ثبت‌شده (HEAD) مقایسه می‌کند.

🔴 و 🟢 نشانه‌های مهم در خروجی:

• - (قرمز): خطوطی که پاک شده یا تغییر یافته‌اند.
• + (سبز): خطوط تازه‌ای که به فایل اضافه شده‌اند.

📜 استعاره داستانی: git diff مثل این است که پروانه شمع را با دقت ذره‌بینی می‌نگرد تا پیش از آنکه پرش بسوزد (کامیت کند)، تمام جزئیات تغییرات را تماشا کند.

❓ چالش تحلیلی

کاتب یک خط جدید به index.html اضافه کرد و با git diff خط سبز را دید. اما به محض زدن git add index.html، اجرای مجدد git diff هیچ خروجی نشان نداد! چرا خروجی خالی شد؟

🎓 جمع‌بندی

آفرین! اکنون می‌توانی با git diff پیش از تصمیم‌گیری برای کامیت، نوشته‌ها را زیر ذره‌بین ببری. در درس بعدی تفاوت بررسی تغییرات معمولی با تغییرات آماده‌شده را خواهی آموخت.

پروانه‌ای در مجمع مرغان گفت: «من می‌خواهم با آتش شمع یکی شوم!» او بارها گرد شمع چرخید تا بال و پرش سوخت. هدهد گفت: «تغییرات شما نیز پیش از ثبت نهایی، از دو پرده می‌گذرد؛ پرده اول درون محیط کار است و پرده دوم روی میز آماده‌سازی (Staging Area)!»

باید بدانی چگونه تغییراتی که به سبد خرید (Staging) فرستاده‌ای را به تنهایی بررسی کنی.

🎯 مسئله

انتقال فایل تغییریافته index.html به Staging Area.

⌨️ اقدام

git add index.html

✅ دستاورد

تغییرات فایل وارد Staging Area شدند.

🎯 مسئله

آزمایش دستور git diff پس از اضافه شدن فایل به Staging Area.

⌨️ اقدام

git diff

✅ دستاورد

خروجی خالی است! زیرا git diff ساده فقط تغییرات اد‌نشده (Working Directory) را نشان می‌دهد.

🎯 مسئله

مشاهده تغییراتی که در Staging Area منتظر کامیت شدن هستند.

⌨️ اقدام

git diff --staged

✅ دستاورد

تمام تفاوت‌های فایل‌های موجود در Staging Area نسبت به آخرین کامیت نمایش داده می‌شود.

⚖️ مقایسه دو فرمان کلیدی

• git diff: مقایسه تغییرات محیط کار (Working Directory) با Staging Area.
• git diff --staged: مقایسه تغییرات Staging Area با آخرین کامیت (Repository).

با این دو فرمان، در هر مرحله تسلط کامل بر تغییرات پروژه خواهی داشت.

💡 چیستی و تفاوت git diff --staged

دستور git diff --staged (یا git diff --cached) تفاوت‌های موجود در «میز آماده‌سازی (Staging Area)» را نسبت به آخرین کامیت موجود در مخزن می‌سنجد.

⚖️ تفاوت با git diff معمولی:

دستور git diff ساده فقط کدهای اد‌نشده (روی هارد) را نشان می‌دهد و اگر فایلی را git add کنید، خروجی آن خالی می‌شود. اما --staged دقیقاً محتویات داخل سبد خرید آماده‌ی کامیت را بازخوانی می‌نماید.

📜 استعاره داستانی: این پرچم مانند بازرسی نهایی برگه‌ها روی میز مجمع پیش از صحافی دائمی است.

🎯 مسئله

کاتب می‌خواهد کدهای فعلی دیسک خود را با یک کامیت عقب‌تر (HEAD~1) مقایسه کند تا بفهمد نسبت به آخرین کامیت چه تغییراتی داشته است.

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

git diff HEAD~1

✅ دستاورد

مشاهده تمام تغییرات اضافه و کم شده نسبت به کامیت قبلی پروژه.

🎯 مسئله

کامیت کردن تغییراتی که با دقت بازبینی و تایید شده‌اند.

⌨️ اقدام

git commit -m "ورود رسمی کاروان به وادی عشق"

✅ دستاورد

تغییرات بررسی‌شده با موفقیت در مخزن ثبت گردید.

❓ چالش سناریویی

کاتب فایل A را stage کرده اما فایل B را هنوز stage نکرده است. او می‌خواهد فقط کدهایی که آماده کامیت بعدی هستند (Staging Area) را بررسی کند. کدام دستور این کار را انجام می‌دهد؟

🎓 جمع‌بندی

فوق‌العاده است! اکنون تفاوت بررسی تغییرات پیش و پس از `git add` را می‌دانی. در درس بعدی راز پنهان‌سازی فایل‌های محرمانه را می‌آموزی.

طوطی سبزپوش پیش آمد و گفت: «من به دنبال آب حیات و چشمه خضر می‌گردم تا جاودانه شوم. اما راز چشمه را نباید هر بی‌گانه و نامحرمی بداند!»

هدهد گفت: «در پروژه‌های نرم‌افزاری نیز فایل‌های محرمانه (مانند رمزهای عبور، کلیدهای دسترسی و فایل‌های موقت) وجود دارند که هرگز نباید وارد مخزن گیت و آلبوم عمومی کاروان شوند!»

🎯 مسئله

ایجاد یک فایل آزمایشی حاوی اطلاعات حساس مانند secret.txt در پوشه پروژه.

⌨️ اقدام

یک فایل جدید به نام secret.txt بساز و متنی محرمانه درون آن بنویس.

✅ دستاورد

فایل محرمانه در پوشه پروژه ایجاد گردید.

🎯 مسئله

مشاهده حضور فایل محرمانه در گزارش عمومی گیت.

⌨️ اقدام

git status

✅ دستاورد

گیت فایل secret.txt را تحت عنوان Untracked به رنگ قرمز نشان می‌دهد؛ اگر حواسمان نباشد ممکن است کامیت شود!

🎯 مسئله

ایجاد فایل ویژه .gitignore برای تعریف قوانین نادیده‌گرفتن فایل‌ها.

⌨️ اقدام

در ریشه پروژه، فایلی دقیقاً به نام .gitignore (با نقطه در ابتدای آن) بساز.

✅ دستاورد

فایل تنظیمات نادیده‌گیری گیت آماده دریافت قوانین است.

🎯 مسئله

اضافه کردن نام فایل محرمانه به فایل .gitignore.

⌨️ اقدام

فایل .gitignore را باز کن و اسم فایل را در خط اول بنویس:

secret.txt

✅ دستاورد

قانون پنهان‌سازی فایل secret.txt ثبت شد.

🎯 مسئله

تایید اینکه گیت دیگر کاری به فایل محرمانه ندارد.

⌨️ اقدام

git status

✅ دستاورد

فایل secret.txt کلاً از گزارش گیت ناپدید شد و فقط خود فایل .gitignore به عنوان فایل جدید دیده می‌شود!

🎯 مسئله

استفاده از کاراکتر الگوی ستاره (*) برای پنهان کردن هم‌زمان تمام فایل‌های با پسوند خاص (مانند `.tmp` یا `.log`).

⌨️ اقدام

خط زیر را به .gitignore اضافه کن:

*.tmp

✅ دستاورد

تمام فایل‌های موقت با پسوند tmp در کل پروژه به صورت خودکار نادیده گرفته می‌شوند.

🎯 مسئله

کامیت کردن خود فایل .gitignore تا تمام اعضای تیم از قوانین نادیده‌گیری باخبر شوند.

⌨️ اقدام

git add .gitignore
git commit -m "افزودن قوانین gitignore"

✅ دستاورد

قوانین محافظت در مخزن ذخیره گشتند.

🎯 مسئله

پوشه‌ای حاوی فایل‌های موقت یا سنگین به نام temp/ ایجاد شده است؛ چگونه کل محتویات این پوشه را از ردیابی گیت مستثنی کنیم؟

⌨️ اقدام

فایل .gitignore را باز کن و خط زیر را به انتهای آن اضافه و ذخیره کن:

temp/

✅ دستاورد

اجرای git status نشان می‌دهد کل پوشه temp/ و فایل‌های درون آن توسط گیت نادیده گرفته شده‌اند.

💡 چیستی و نقش فایل .gitignore در پروژه

فایل .gitignore یک «سپر محافظ و لیست سیاه گیت» است. هر اسم یا الگویی که درون این فایل نوشته شود، به گیت می‌گوید: «این فایل‌ها را برای همیشه نادیده بگیر و هرگز در git status نشان نده!»

🔒 چه چیزهایی باید در .gitignore قرار گیرند؟

• کلیدهای محرمانه API و رمزهای عبور (مانند فایل .env).
• فایل‌های موقت، لوگ‌ها (*.log) و پوشه‌های سنگین پکیج‌ها (مانند node_modules/).

📜 استعاره داستانی: .gitignore مانند پرده‌ای پنهان‌کننده است که اسرار محرمانه چشمه آب حیات طوطی را از چشم نامحرمان نگه می‌دارد.

❓ چالش عیب‌یابی پیشرفته

کاتب فایل محرمانه db_pass.env را قبلاً کامیت کرده بود. حالا اسم آن را در .gitignore می‌نویسد اما گیت هنوز تغییراتش را در status نشان می‌دهد! چرا .gitignore کار نکرده است؟

🎓 جمع‌بندی

خسته نباشی ای نگهبان هوشمند! با `.gitignore` امنیت اطلاعات کاروان تضمین شد. در درس بعد بازگرداندن اشتباهات با `git restore` را یاد می‌گیریم.

بلبل در میانه راه، از شدت سوز دل، نغمه‌ای اشتباه سر داد و کلامش پریشان شد. نالید که: «ای هدهد! من سخنی نادرست بر زبان آوردم و دفتر خراب شد!»

هدهد پاسخ داد: «نگران نباش! تا زمانی که تغییر اشتباه کامیت نشده باشد، گیت به تو قدرتی جادویی به نام git restore می‌دهد تا نوشته‌ها را به آخرین کامیت سالم بازگردانی!»

🎯 مسئله

دستکاری اشتباه یا پاک کردن بخشی از متن فایل index.html برای تمرین بازیابی.

⌨️ اقدام

یک خط از فایل index.html را پاک کن و فایل را ذخیره (Save) کن.

✅ دستاورد

فایل خراب شد اما هنوز `git add` یا کامیت نشده است.

🎯 مسئله

مشاهده حذف اشتباهی خط در ترمینال.

⌨️ اقدام

git diff

✅ دستاورد

مشاهده خط قرمز حذف‌شده که تایید می‌کند فایل دچار دستکاری شده است.

🎯 مسئله

ابطال تمام تغییرات ثبت‌نشده در محیط کار و بازگشت به آخرین کامیت.

⌨️ اقدام

git restore index.html

✅ دستاورد

تمام تغییرات اشتباهی لغو شد و فایل دقیقا به حالت اولیه و سالم بازگشت!

🎯 مسئله

مشاهده نتیجه بازیابی جادویی در مرورگر.

⌨️ اقدام

مرورگر را رفرش (Refresh) کن و سورس کد فایل index.html در VS Code را ببین.

✅ دستاورد

خط حذف‌شده دوباره سر جای اولش برگشته است.

🎯 مسئله

اگر کاتب اشتباهاً فایل style.css را از روی هارد دیسک پاک کرده باشد، چگونه آن را از آخرین کامیت زنده به دیسک برگرداند؟

⌨️ اقدام

دستور زیر را در ترمینال وارد کن:

git restore style.css

✅ دستاورد

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

💡 چیستی و کارکرد دستور git restore

دستور git restore ابزار «پاک‌کن جادویی و لغو تغییرات نخواسته در محیط کار» است.

⚠️ هشدار مهم فنی:

اگر فایلی را ویرایش کرده باشید اما هنوز git add یا کامیت نکرده باشید، با اجرای git restore filename تمام تغییرات جدید روی هارد دیسک پاک شده و فایل دقیقاً به آخرین کامیت سالم برمی‌گردد. این عمل غیرقابل بازگشت است!

📜 استعاره داستانی: git restore آواز اشتباه بلبل را پیش از ثبت در تاریخچه پاک می‌کند تا دفتر سفر همواره در کمال سلامت باقی بماند.

❓ چالش بازیابی فایل

کاتب به اشتباه تمام کدهای index.html را پاک کرده و فایل را ذخیره نمود، اما هنوز git add یا کامیتی نزده است. او چگونه می‌تواند با یک دستور، فایل دیسک را به آخرین کامیت سالم بازگرداند؟

🎓 جمع‌بندی

آواز بلبل دوباره صاف و زیبا شد! با `git restore` هیچ اشتباه اولیه و ثبت‌نشده‌ای فاجعه نخواهد بود. در درس آخر، لغو کردن مرحله Staging را یاد می‌گیریم.

پرنده نامه‌رسان با شتاب فراوان نامه‌ای را قبل از بررسی نهایی هدهد، پاکنویس کرد و روی میز آماده‌سازی نهاد. هدهد گفت: «ای پرنده تیزپا! شتاب‌زدگی در کاروان جایی ندارد. اگر فایلی را اشتباهاً `git add` کردی، باید بتوانی آن را از میز Staging به محیط کار برگردانی بدون اینکه نوشته‌هایت پاک شوند!»

🎯 مسئله

نوشتن یک عبارت آزمایشی اشتباه در فایل index.html.

⌨️ اقدام

تگ جدیدی به صورت <p>گزارش اشتباهی</p> اضافه کن.

✅ دستاورد

تغییر اشتباه ایجاد شد.

🎯 مسئله

اشتباهی اجرا کردن دستور `git add` برای فایلی که هنوز آماده ثبت نیست.

⌨️ اقدام

git add index.html

✅ دستاورد

فایل وارد Staging Area گردید.

🎯 مسئله

مشاهده وضعیت فایل در صف کامیت.

⌨️ اقدام

git status

✅ دستاورد

مشاهده رنگ سبز و عبارت Changes to be committed.

🎯 مسئله

بیرون کشیدن فایل از Staging Area بدون پاک شدن نوشته‌های آن.

⌨️ اقدام

git restore --staged index.html

✅ دستاورد

فایل از Staging Area خارج شد و به محیط کار (Working Directory) بازگشت.

🎯 مسئله

تایید اینکه پرچم `--staged` کدهای شما را پاک نکرده است.

⌨️ اقدام

git status

✅ دستاورد

مشاهده رنگ قرمز و عبارت modified: index.html که نشان می‌دهد تغییرات در محیط کار باقی مانده‌اند.

💡 چیستی و عملکرد git restore --staged (Unstaging)

دستور git restore --staged فایل‌ها را «از میز Staging Area خارج می‌کند (Unstage) بدون آنکه کدهای شما روی هارد دیسک پاک شوند!»

🔄 تفاوت با restore معمولی:

• git restore filename: کدهای ویرایش‌شده روی هارد را کاملاً پاک می‌کند.
• git restore --staged filename: فایل را فقط از صف کامیت بیرون می‌آورد تا بتوانید دوباره آن را بررسی کنید، اما کدها روی سیستم دست‌نخورده باقی می‌مانند.

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

🎯 مسئله

کاتب چندین فایل را به اشتباه با git add . وارد Staging Area کرده است؛ چگونه همه آن‌ها را یکجا بدون پاک شدن ویرایش‌ها خارج (Unstage) کند؟

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

git restore --staged .

✅ دستاورد

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

🎯 مسئله

حالا که فایل unstage شده، پاک کردن کامل تغییر اشتباهی از محیط کار.

⌨️ اقدام

git restore index.html

✅ دستاورد

فایل کاملاً تمیز شد و تغییر اشتباه لغو گردید.

❓ چالش تحلیل ریسک

فرق حیاتی دو دستور git restore index.html و git restore --staged index.html در چیست و اجرای کدام‌یک باعث پاک شدن دائمی تغییرات کد روی هارد دیسک می‌شود؟

🏆 تبریک! نشان «❤️ نشان وادی عشق» آزاد شد

با موفقیت وادی عشق را پشت سر گذاشتی! اکنون بر ابزارهای بررسی diff، فایل .gitignore و دستورات restore کاملاً مسلط هستی. در فصل بعد وارد وادی معرفت می‌شویم...

کاروان پرندگان وارد سومین مرحله سلوک یعنی وادی معرفت گردید. وادی معرفت، دشتِ دیدن راه‌های گوناگون است.

بعد از آن بنمود وادیّ معرفت
نیست آن وادی را حدّ و صفت
هیچ کس نشنود بر این راه معین
هر یکی بر قدر بینایی خویش

هدهد فرمود: «چون پرندگان تفاوت بسیار دارند، هر گروه می‌تواند در شاخه‌ای جداگانه (Branch) پرواز کند بدون آنکه راه دیگری را سد نماید!»

🌿 شاخه (Branch) در گیت چیست؟

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

تاکنون تمام کار ما روی شاخه اصلی یعنی main انجام می‌شد، اما از این پس خطوط پرواز موازی می‌سازیم!

🎯 مسئله

مشاهده لیست شاخه‌های موجود در پروژه و تشخیص شاخه فعال فعلی.

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

git branch

✅ دستاورد

نمایش لیست شاخه‌ها (در حال حاضر فقط * main با ستاره سبز دیده می‌شود).

🎯 مسئله

ایجاد یک شاخه موازی جدید برای ثبت فهرست پرندگان بدون دست زدن به شاخه اصلی.

⌨️ اقدام

git branch feature/birds

✅ دستاورد

شاخه جدید feature/birds با موفقیت در مخزن متولد شد.

🎯 مسئله

بررسی اضافه شدن شاخه جدید به لیست شاخه‌های مخزن.

⌨️ اقدام

git branch

✅ دستاورد

مشاهده دو نام main و feature/birds در ترمینال.

🎯 مسئله

کاتب می‌خواهد علاوه بر نام شاخه‌های موجود، آخرین کامیت ثبت‌شده روی هر شاخه را نیز به صورت خلاصه ببیند.

⌨️ اقدام

پرچم -v (Verbose) را جلوی دستور branch در ترمینال اضافه کن:

git branch -v

✅ دستاورد

نمایش فهرست تمام شاخه‌ها همراه با کد هش و عنوان آخرین کامیت ثبت‌شده روی آن‌ها.

💡 چیستی و ماهیت شاخه (Branch) در گیت

شاخه در گیت بر خلاف سایر سیستم‌های قدیمی، بسیار سبک و سریع است. یک شاخه فقط «یک اشاره‌گر متحرک (Pointer) ۴۰ کاراکتری به آخرین کامیت» است!

🌱 چرا به شاخه‌بندی نیاز داریم؟

شاخه‌بندی به شما اجازه می‌دهد محیط‌های آزمایشگاهی ایزوله‌ای بسازید تا پروژه‌های بزرگ بدون ریسکِ خراب شدن کد اصلی (main) توسعه یابند.

📜 استعاره داستانی: شاخه‌بندی مانند پرواز گروه‌های مختلف پرندگان در مسیرهای موازی آسمان است بدون آنکه بال‌هایشان به یکدیگر برخورد کند.

⭐ نشانه شاخه فعال چیست؟

وقتی دستور git branch را می‌زنی، علامت ستاره (*) و رنگ سبز روی نام یکی از شاخه‌ها قرار دارد. این نشانه به معنای «شاخه فعال پروژه (HEAD)» است.

توجه داشته باش که با دستور git branch شاخه ساخته می‌شود، اما هنوز به آن منتقل نشده‌ای!

❓ چالش تحلیلی

کاتب دستور git branch feature/birds را اجرا نمود. او بلافاصله چند خط کد جدید نوشت و کامیت کرد. اما با تعجب دید کدهای جدید روی شاخه main ثبت شده‌اند نه feature/birds! چرا این اتفاق افتاد؟

🎓 جمع‌بندی

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

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

در گیت، برای ورود به یک شاخه جدید و کار در آن، از دستور git switch استفاده می‌کنیم.

🎯 مسئله

جابه‌جایی محیط کاری به شاخه feature/birds.

⌨️ اقدام

git switch feature/birds

✅ دستاورد

پیام Switched to branch 'feature/birds' در ترمینال صادر می‌شود.

🔄 دستور قدیمی‌تر: git checkout

در گذشته (و هنوز در بسیاری از پروژه‌ها)، از دستور git checkout feature/birds برای جابه‌جایی استفاده می‌شد.

دستور جدید git switch در نسخه‌های اخیر گیت معرفی شده تا جابه‌جایی شاخه‌ها ساده‌تر و روشن‌تر باشد، اما هر دو یک کار را انجام می‌دهند.

💡 چیستی سوییچ کردن و مفهوم اشاره‌گر HEAD

وقتی دستور git switch branch-name (یا git checkout) را اجرا می‌کنید، گیت اشاره‌گر HEAD (موقعیت فعلی شما) را به شاخه جدید وصل کرده و کدهای روی هارد دیسک شما را دقیقاً بازنویسی می‌کند تا با آن شاخه همگام شود.

🔄 تفاوت switch و checkout:

دستور git checkout قدیمی‌تر بود و هم برای جابه‌جایی شاخه‌ها و هم برای بازگرداندن فایل‌ها استفاده می‌شد. گیت دستور تخصصی git switch را معرفی کرد تا وظیفه جابه‌جایی شاخه‌ها کاملاً مجزا و واضح شود.

📜 استعاره داستانی: switch کردن مانند گشودن نگاه کاتب به برگه کاروان جانبی است که ناگهان کلمات برگه اصلی جلوی چشمش غیب شده و کلمات برگه جدید ظاهر می‌شوند.

🎯 مسئله

اضافه کردن یک لیست HTML جدید از پرندگان در شاخه feature/birds.

⌨️ اقدام

کد زیر را به انتهای index.html اضافه کن:

<h3>🦅 فهرست همراهان کاروان</h3>
<ul>
  <li>هدهد دانا</li>
  <li>بلبل شیدا</li>
  <li>طوطی سبزپوش</li>
  <li>باز شکاری</li>
</ul>

✅ دستاورد

فهرست پرندگان فقط در این شاخه ایجاد گردید.

🎯 مسئله

کامیت کردن تغییرات روی همین شاخه اختصاصی.

⌨️ اقدام

git commit -am "افزودن فهرست پرندگان کاروان"

✅ دستاورد

کامیت جدید روی شاخه feature/birds ذخیره شد.

🎯 مسئله

بازگشت به شاخه اصلی main و جادوی غیب شدن کدهای شاخه جانبی!

⌨️ اقدام

دستور زیر را بزن و سپس فایل index.html را در VS Code نگاه کن:

git switch main

✅ دستاورد

فهرست پرندگان غیب شد! زیرا آن کدها فقط در شاخه feature/birds وجود دارند و شاخه main همچنان دست‌نخورده باقی مانده است.

🎯 مسئله

میانبر ساخت شاخه جدید و سوییچ آنی به آن تنها با یک دستور.

⌨️ اقدام

git switch -c feature/notes

✅ دستاورد

شاخه feature/notes ساخته شد و بلافاصله به آن منتقل شدی.

🎯 مسئله

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

⌨️ اقدام

علامت خط تیره (-) را جلوی دستور switch در ترمینال وارد کن:

git switch -

✅ دستاورد

جابه‌جایی سریع و هوشمندانه به شاخه قبلی همراه با پیام تغییر اشاره‌گر HEAD.

💡 چیستی پرچم‌های -c و -b در سوییچ شاخه

پرچم -c (در git switch -c) مخفف Create، و پرچم -b (در git checkout -b) مخفف Branch است.

⚡ دو دستور در یک حرکت:

این میانبرها ابتدا شاخه را خلق می‌کنند (git branch) و بلافاصله اشاره‌گر شما را وارد آن می‌کنند (git switch)، که فرآیند کدنویسی را فوق‌العاده سریع‌تر می‌کند.

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

💡 میانبر سنتی: git checkout -b

عبارت git checkout -b دقیقا همان کاری را انجام می‌دهد که git switch -c انجام می‌دهد.

هر دو دستور یک شاخه جدید ساخته و شما را فوراً وارد آن می‌کنند.

❓ چالش درک ابزار

کاتب در شاخه feature/birds است و تغییراتی را کامیت کرده است. او ناگهان دستور git switch main را می‌زند تا به main برگردد. گیت کدهای شاخه قبل را غیب می‌کند. این قابلیت ایزوله‌سازی چگونه کار می‌کند؟

🎓 جمع‌بندی

عالی بود! حالا می‌دانی چگونه در شاخه‌های ایزوله کد بنویسی بدون اینکه شاخه main تحت تاثیر قرار گیرد. در درس بعد پیوند دادن کدهای این شاخه‌ها به اصلی را یاد می‌گیریم.

گروه هدهد پس از تکمیل فهرست پرندگان به شاهراه اصلی کاروان بازگشتند. اکنون وقت آن است که دستاورد شاخه جانبی با دفتر اصلی کاروان پیوند خورده و ادغام (Merge) شود.

دستور git merge شاخه جانبی را پیوند داده و کدهای آن را وارد شاخه فعلی می‌کند.

🎯 مسئله

برای ادغام هر شاخه، ابتدا باید خودت روی شاخه‌ای ایستاده باشی که می‌خواهی تغییرات وارد آن شوند (مقصد).

⌨️ اقدام

git switch main

✅ دستاورد

ورود به شاخه اصلی main.

🎯 مسئله

پیوند دادن تغییرات شاخه feature/birds به شاخه main.

⌨️ اقدام

git merge feature/birds

✅ دستاورد

پیام Fast-forward یا Merge صادر شده و تمام کدهای فهرست پرندگان وارد شاخه main گردید.

🎯 مسئله

تایید این موضوع که کدهای ادغام شده اکنون در شاخه main آماده نمایش هستند.

⌨️ اقدام

مرورگر را رفرش (Refresh) کن و سورس فایل index.html را ببین.

✅ دستاورد

فهرست پرندگان با موفقیت روی شاخه main قرار گرفت.

🎯 مسئله

مشاهده پیوند دو شاخه در نمودار لاگ گیت.

⌨️ اقدام

git log --oneline --graph

✅ دستاورد

مشاهده یکپارچه شدن کامیت‌های شاخه جانبی در خط اصلی تاریخچه.

💡 چیستی و عملکرد دستور git merge

دستور git merge branch-name تاریخچه دو شاخه جداگانه را به یکدیگر پیوند داده و ادغام می‌کند.

🔀 انواع ادغام در گیت:

• Fast-forward: اگر شاخه اصلی پس از جدا شدن تغییر نکرده باشد، گیت فقط اشاره‌گر اصلی را سریعاً جلو می‌برد.
• 3-Way Merge: اگر هر دو شاخه پیش رفته باشند، گیت یک کامیت ویژه ادغام (Merge Commit) خلق می‌کند.

📜 استعاره داستانی: git merge پیوستن دو گروه از کاروان پرندگان در یک نقطه الحاق آسمان است تا تمام گزارش‌های پراکنده یکپارچه شوند.

🎯 مسئله

گاهی کاتب می‌خواهد هنگام ادغام شاخه، حتماً یک کامیت ادغام (Merge Commit) ایجاد شود تا نقطه اتصال شاخه‌ها در گراف ماندگار بماند.

⌨️ اقدام

پرچم --no-ff را هنگام merge اجرا کن:

git merge --no-ff feature/birds

✅ دستاورد

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

🎯 مسئله

پاک‌سازی و حذف شاخه جانبی پس از ادغام موفق کدهای آن.

⌨️ اقدام

git branch -d feature/birds

✅ دستاورد

شاخه اضافی حذف گردید و فهرست شاخه‌ها خلوت و مرتب شد.

❓ چالش مفهوم اشاره‌گر

کاتب کارهای شاخه feature/birds را تمام کرده و آن را با موفقیت درون main ادغام می‌نماید. حالا دستور git branch -d feature/birds را اجرا می‌کند. چرا حذف این شاخه کدهای پروژه را پاک نمی‌کند؟

🎓 جمع‌بندی

کار بسیار تمیزی بود! کدهای شاخه جدید با موفقیت ادغام و شاخه اضافی تمیز شد. در درس بعد برخورد با برخوردها یا تعارضات (Merge Conflicts) را یاد می‌گیریم.

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

📖 حکایت اختلاف باز و بلبل: باز گفت من شاهانه‌ام و بلبل گفت من عاشق‌پیشه‌ام! هدهد در میان آمد و هر دو نظر را شنید و گفت از ترکیب هوشمندانه هر دو حکایتی بسازید. در گیت وقتی دو تغییر هم‌زمان روی یک خط ثبت شوند، تعارض (Merge Conflict) رخ می‌دهد که کاتب کاروان باید با درایت آن را حل کند!

🎯 مسئله

ساخت یک شاخه تازه برای ثبت روایت بلبل.

⌨️ اقدام

git switch -c feature/nightingale

✅ دستاورد

وارد شاخه اختصاصی بلبل شدیم.

🎯 مسئله

ویرایش خط وضعیت در فایل index.html به روایت بلبل و کامیت کردن آن.

⌨️ اقدام

متن وضعیت را تغییر بده و کامیت کن:

<p>وضعیت: کاروان با ترنم نغمه‌های بلبل پیش می‌رود.</p>

git commit -am "گزارش وضعیت به روایت بلبل"

✅ دستاورد

کامیت بلبل ثبت شد.

🎯 مسئله

بازگشت به main و تغییر همان خط به روایت باز شکاری.

⌨️ اقدام

git switch main

همان خط متن وضعیت را در main به این عبارت تغییر بده و کامیت کن:

<p>وضعیت: کاروان با شکوه و اوج پرواز باز پیش می‌رود.</p>

git commit -am "گزارش وضعیت به روایت باز"

✅ دستاورد

حالا دقیقاً دو کامیت متناقض روی یک خط واحد در دو شاخه مختلف داریم!

🎯 مسئله

تلاش برای ادغام شاخه بلبل روی main و ایجاد اولین تعارض (Conflict).

⌨️ اقدام

git merge feature/nightingale

✅ دستاورد

گیت پیام CONFLICT (content): Merge conflict in index.html صادر می‌کند و ادغام متوقف می‌شود تا تعارض حل شود.

⚠️ علامت‌های تعارض چیستند؟

اگر فایل index.html را باز کنی، گیت کدهای زیر را قرار داده است:

<<<<<<< HEAD
<p>وضعیت: کاروان با شکوه و اوج پرواز باز پیش می‌رود.</p>
=======
<p>وضعیت: کاروان با ترنم نغمه‌های بلبل پیش می‌رود.</p>
>>>>>>> feature/nightingale

• <<<<<<< HEAD: کد فعلی شاخه اصلی تو.
• =======: مرز جداکننده دو کد.
• >>>>>>>: کدی که از شاخه دیگر وارد شده است.

💡 چیستی و نحوه مواجهه با Merge Conflict

تضاد ادغام یا Merge Conflict زمانی اتفاق می‌افتد که دو کامیت مختلف روی «دقیقاً یک خط از یک فایل» تغییر ایجاد کرده باشند و گیت نتواند به تنهایی حدس بزند کدام کد درست است.

🧩 چرخه ۳ مرحله‌ای حل تعارض:

1. فایل را باز کرده و علامت‌های <<<<<<< و ======= و >>>>>>> را پاک و کد نهایی را اصلاح کنید.
2. دستور git add filename را بزنید تا گیت بفهمد تعارض حل شده است.
3. دستور git commit را بزنید تا کامیت ادغام با موفقیت ثبت شود.

📜 استعاره داستانی: تعارض مانند اختلاف روایت بلبل و باز است که کاتب دانا با درایت هر دو را ترکیب کرده و داستانی یکپارچه می‌سازد.

🎯 مسئله

استفاده از ابزار تصویری حل تعارض (Resolve in Merge Editor) در VS Code.

⌨️ اقدام

در پایین سمت راست فایل در VS Code روی دکمه Resolve in Merge Editor کلیک کن (یا دکمه‌های Accept Current / Accept Incoming بالای کد را ببین).

✅ دستاورد

محیط دو پنجره‌ای مقایسه کد در VS Code باز می‌شود.

🎯 مسئله

حل تعارض با ترکیب محترمانه کلام بلبل و باز در یک خط زیبا.

⌨️ اقدام

علامت‌های <<<<<<< و ======= و >>>>>>> را پاک کن و متن نهایی را به صورت زیر جایگزین و ذخیره کن:

<p>وضعیت: کاروان با شکوه باز و نغمه‌های بلبل پیش می‌رود.</p>

✅ دستاورد

تعارض کد به نفع ترکیب هر دو روایت حل گردید.

🎯 مسئله

اعلام پایان حل تعارض به گیت و ثبت کامیت ادغام (Merge Commit).

⌨️ اقدام

git add index.html
git commit -m "حل تعارض و ترکیب گزارش بلبل و باز"

✅ دستاورد

کامیت ادغام با موفقیت ثبت شد و فرآیند Merge به پایان رسید!

🎯 مسئله

اگر هنگام ادغام شاخه‌ها با تداخل شدید (Merge Conflict) روبه‌رو شویم و کاتب بخواهد کلاً عملیات ادغام را کنسل کرده و به حالت قبل برگردد چه کند؟

⌨️ اقدام

دستور زیر را در حالت تعارض اجرا کن:

git merge --abort

✅ دستاورد

لغو کامل عملیات ادغام و بازگشت پروژه به حالت تمیز قبل از شروع merge.

🎯 مسئله

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

⌨️ اقدام

git log --graph --oneline

✅ دستاورد

دیدن گراف پیوستن شاخه بلبل به شاخه main.

❓ چالش سناریویی حل تعارض

کاتب هنگام اجرای git merge feature/nightingale با پیغام CONFLICT (content): Merge conflict in index.html مواجه می‌شود و ادغام متوقف می‌گردد. چرخه گام‌های صحیح کاتب برای حل این تعارض و تکمیل ادغام چیست؟

🏆 تبریک! نشان «🌿 نشان وادی معرفت» آزاد شد

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

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

بعد از آن وادیّ استغنا بود
نه ادعا و نه در دعوا بود
هفت دریا نزد این وادی ید است
هفت دوزخ نزد این آتش ید است

📖 حکایت بازرگان و طوفان دریا: بازرگانی در طوفان، کالاهای نیمه‌کاره را در انبار قایق مکتوم ساخت تا کشتی سبک شود و بعد از طوفان دوباره آن‌ها را برداشت! هدهد رو به طوطی کرد و گفت: «از انبار جادویی گیت (Stash) استفاده کن تا تغییرات نیمه‌کاره‌ات مکتوم شوند!»

🎯 مسئله

ایجاد یک تغییر نیمه‌کاره در فایل index.html بدون ثبت کامیت.

⌨️ اقدام

یک پاراگراف نیمه‌کاره مانند <p>گزارش طوطی در حال...</p> در فایل اضافه کن و فایل را ذخیره کن.

✅ دستاورد

فایل تغییر یافته اما کدها هنوز آماده کامیت رسمی نیستند.

🎯 مسئله

دیدن وضعیت فایل‌های تغییریافته نیمه‌کاره در ترمینال.

⌨️ اقدام

git status

✅ دستاورد

مشاهده وضعیت قرمز modified برای فایل index.html.

🎯 مسئله

مخفی و ذخیره کردن موقت تغییرات نیمه‌کاره در انبار گیت برای تمیز شدن محیط کار.

⌨️ اقدام

git stash

✅ دستاورد

پیام Saved working directory and index state صادر شده و تمام تغییرات موقتاً کنار گذاشته می‌شوند.

🎯 مسئله

تایید تمیز شدن محیط کاری پس از stash.

⌨️ اقدام

git status

✅ دستاورد

مشاهده عبارت working tree clean؛ اکنون آماده انجام کار فوری هستید!

💡 چیستی و ماهیت انبار موقت (git stash)

دستور git stash به زبان ساده «کشوی مخفی و انبار موقت گیت» است. وقتی کدهایی را ویرایش کرده‌اید اما هنوز آماده کامیت نیستند و ناگهان مجبور می‌شوید روی یک باگ یا شاخه دیگر کار کنید، git stash تمام تغییرات را موقتاً کنار گذاشته و محیط کار را کاملاً تمیز می‌کند.

📦 ساختار پشته‌ای (Stack):

انبار گیت به صورت یک پشته (LIFO: Last In, First Out) عمل می‌کند؛ یعنی آخرین تغییراتی که stash می‌کنید، در بالای انبار قرار می‌گیرد (stash@{0}).

📜 استعاره داستانی: git stash مانند مکتوم ساختن کالاهای نیمه‌کاره بازرگان در انبار قایق در میانه طوفان است تا قایق سبک شده و سفر به خطر نیفتد.

🎯 مسئله

انجام و ثبت کار فوری هدهد در محیط کاری تمیز.

⌨️ اقدام

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

git commit -am "اصلاح فوری عنوان دفتر در وادی استغنا"

✅ دستاورد

کامیت فوری با موفقیت ثبت شد.

🎯 مسئله

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

⌨️ اقدام

git stash list

✅ دستاورد

مشاهده گزینه‌ای مانند stash@{0}: WIP on main در ترمینال.

🎯 مسئله

خارج کردن آخرین کار نیمه‌کاره از انبار و بازگرداندن آن به محیط کار.

⌨️ اقدام

git stash pop

✅ دستاورد

پاراگراف نیمه‌کاره طوطی دوباره در فایل index.html ظاهر می‌شود!

🎯 مسئله

کاتب می‌خواهد هنگام ذخیره کارهای نیمه‌کاره در انبار (Stash)، یک پیام راهنما روی آن بگذارد تا بعداً میان تغییرات مختلف به راحتی شناسایی شود.

⌨️ اقدام

پرچم push -m را با پیام اختصاصی در دستور stash استفاده کن:

git stash push -m "WIP: کارهای نیمه‌کاره فهرست طوطی"

✅ دستاورد

ذخیره کارهای نیمه‌تمام همراه با عنوان شفاف در لیست git stash list.

🎯 مسئله

کامل کردن متن نیمه‌کاره طوطی و ثبت رسمی آن.

⌨️ اقدام

پاراگراف را کامل کن و کامیت بزن:

git commit -am "تکمیل و ثبت گزارش طوطی"

✅ دستاورد

گزارش طوطی بدون هیچ آسیبی در تاریخچه ثبت شد.

❓ چالش تحلیلی

کاتب در حال افزودن یک بخش به فایل است که هدهد دستور می‌دهد فوراً یک باگ بحرانی را روی شاخه main رفع کند. کدهای او نیمه‌کاره‌اند. اگر بدون کامیت دستور git switch main را بزند، چه اتفاقی می‌افتد و راه حل چیست؟

🎓 جمع‌بندی

عالی بود! با `git stash` دیگر نگران کارهای نیمه‌کاره هنگام کارهای اضطراری نخواهی بود. در درس بعدی پاک‌سازی بارهای اضافی از انبار را یاد می‌گیریم.

پرنده‌ای خسته در وادی استغنا پیش آمد که سنگ‌ها و بارهای بی‌ارزش فراوان بر دوش داشت. هدهد بانگ برآورد: «این همه بار بی‌فایده برای چیست؟ آن را رها کن تا سبکبال پرواز کنی!»

گاهی در گیت، تغییراتی را انبار (Stash) کرده‌ایم اما بعداً متوجه می‌شویم اصلاً به آن‌ها نیازی نداریم و باید کلاً پاک شوند.

🎯 مسئله

ایجاد یک تغییر بی‌فایده در فایل برای تمرین حذف انبار.

⌨️ اقدام

یک متن تکراری آزمایشی در index.html بنویس.

✅ دستاورد

تغییر اضافی آماده شد.

🎯 مسئله

انتقال تغییر اضافی به انبار.

⌨️ اقدام

git stash

✅ دستاورد

تغییر اضافی وارد انبار گیت شد.

🎯 مسئله

مشاهده شناسه انبار (مانند `stash@{0}`).

⌨️ اقدام

git stash list

✅ دستاورد

شناسه آیتم انبار در لیست مشاهده شد.

🎯 مسئله

حذف دائمی آیتم اضافی انبار بدون اعمال آن روی فایل‌ها.

⌨️ اقدام

git stash drop

✅ دستاورد

پیام Dropped refs/stash@{0} صادر شده و انبار کلاً پاک می‌شود.

🎯 مسئله

اطمینان از خالی شدن لیست انبار.

⌨️ اقدام

git stash list

✅ دستاورد

هیچ آیتمی در لیست انبار باقی نمانده است.

🎯 مسئله

کاتب می‌خواهد کارهای درون انبار را روی دیسک پیاده کند، اما در عین حال می‌خواهد یک کپی از آن همچنان درون انبار Stash باقی بماند.

⌨️ اقدام

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

git stash apply

✅ دستاورد

تغییرات روی دیسک اعمال شده اما نسخه انبار در git stash list حفظ می‌گردد.

💡 چیستی تفاوت دستورات مدیریت انبار گیت

پس از ذخیره تغییرات در انبار، گیت سه ابزار برای مدیریت آن در اختیارتان می‌گذارد:

• git stash pop: آخرین تغییر انبار را روی فایل‌ها اعمال کرده و آن را از لیست انبار پاک می‌کند.
• git stash apply: تغییر انبار را روی فایل‌ها اعمال می‌کند اما نسخه‌ای از آن را در انبار نگه می‌دارد.
• git stash drop: تغییر انبار را بدون اعمال روی کدها، برای همیشه پاک و نابود می‌کند.

📜 استعاره داستانی: git stash drop بیرون انداختن بارهای سنگین بی‌ارزش از قایق در وادی استغناست تا سالک سبکبال حرکت کند.

❓ چالش مقایسه ابزار

فرق کلیدی دستور git stash pop و git stash apply چیست و چه زمانی بهتر است از apply به جای pop استفاده کنیم؟

🎓 جمع‌بندی

فوق‌العاده بود! بارهای اضافی حذف شدند. در درس بعد سفر در زمان با دستور `git reset --soft` را مرور خواهیم کرد.

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

گیت ابزاری چون ماشین زمان به نام git reset --soft دارد که کامیت قبلی را لغو می‌کند اما تمام نوشته‌های شما را به صورت سالم روی میز Staging نگه می‌دارد تا اصلاحشان کنید!

🎯 مسئله

ایجاد یک شاخه اختصاصی برای تمرین بی‌خطر دستورات ریست.

⌨️ اقدام

git switch -c feature/time-machine

✅ دستاورد

ورود به شاخه feature/time-machine.

🎯 مسئله

ساخت یک کامیت با پیام شتاب‌زده.

⌨️ اقدام

یک خط جدید به index.html اضافه کن و کامیت بزن:

git commit -am "کامیت شتاب زده طوطی"

✅ دستاورد

کامیت اشتباه در شاخه آزمایشی ثبت شد.

🎯 مسئله

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

⌨️ اقدام

git log --oneline

✅ دستاورد

دیدن کامیت جدید در بالای لاگ (HEAD).

🎯 مسئله

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

⌨️ اقدام

git reset --soft HEAD~1

✅ دستاورد

کامیت لغو گردید اما کدهای شما آسیب ندیدند!

🎯 مسئله

تایید اینکه تمام کدها اکنون در Staging Area آماده ویرایش هستند.

⌨️ اقدام

git status

✅ دستاورد

فایل به رنگ سبز در بخش Changes to be committed قرار دارد.

💡 چیستی و کارکرد بازگشت نرم (git reset --soft)

دستور git reset --soft HEAD~1 ماشین زمانِ بدون خطر گیت است. این دستور اشاره‌گر شاخه و HEAD را یک یا چند کامیت به عقب برمی‌گرداند، اما تمام کدهای شما را به صورت سالم درون Staging Area باقی می‌گذارد.

🎯 چه زمانی از --soft استفاده می‌کنیم؟

وقتی فایلی را شتاب‌زده کامیت کرده‌اید و می‌خواهید پیام کامیت را اصلاح کنید یا چند خط کد جدید به همان کامیت اضافه کرده و دوباره آن را ثبت کنید.

📜 استعاره داستانی: reset --soft مانند باز کردن موم نامه شتاب‌زده است تا کاتب بدون از دست دادن کلمات، غلط‌های املایی را اصلاح کند.

🎯 مسئله

کاتب می‌خواهد ۲ کامیت اخیر پروژه را به عقب برگرداند اما تمام فایل‌های تغییریافته آن دو کامیت را در Staging Area به صورت سبز و آماده ترکیب نگه دارد.

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

git reset --soft HEAD~2

✅ دستاورد

اصلاح تاریخچه و قرار گرفتن تمام تغییرات دو کامیت قبلی درون Staging Area.

🎯 مسئله

ثبت مجدد کامیت با یک پیام اصلاح‌شده و کاملاً درست.

⌨️ اقدام

git commit -m "گزارش درست و اصلاح‌شده طوطی"

✅ دستاورد

کامیت تمیز و اصلاح‌شده در تاریخچه ثبت شد.

❓ چالش درک ابزار

کاتب کدی را کامیت کرد اما متوجه غلط املایی در پیام شد. او دستور git reset --soft HEAD~1 را اجرا کرد. کدهایی که در کامیت لغوشده بودند اکنون در کدام وضعیت (State) قرار می‌گیرند؟

🎓 جمع‌بندی

آفرین! با `git reset --soft` یاد گرفتی چگونه بدون نابود کردن کدهایت، کامیت‌های قبلی را اصلاح کنی. در درس بعدی بازگشت سخت (Hard Reset) را بررسی می‌کنیم.

کاروان به پرتگاهی تند رسید. هدهد با صدایی رسا هشدار داد: «مواظب باشید! در گیت دستوری به نام git reset --hard وجود دارد که مانند سقوط در پرتگاه است؛ تمام کامیت‌ها و تغییرات کدهای بعدی شما برای همیشه نابود خواهند شد و راه بازگشتی نیست!»

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

🎯 مسئله

اطمینان از اینکه روی شاخه آزمایشی feature/time-machine هستیم تا شاخه اصلی آسیب نبیند.

⌨️ اقدام

git status

✅ دستاورد

اطمینان از وجود در شاخه آزمایشی.

🎯 مسئله

ایجاد یک کامیت اشتباهی که می‌خواهیم کلاً محو شود.

⌨️ اقدام

متنی بی‌ربط در index.html بنویس و کامیت کن:

git commit -am "تغییر خرابکاری آزمایشی"

✅ دستاورد

کامیت خراب ایجاد گردید.

🎯 مسئله

مشاهده لاگ برای تعیین کامیت سالمی که می‌خواهیم به آن عقب‌گرد کنیم.

⌨️ اقدام

git log --oneline

✅ دستاورد

مشاهده شناسه کامیت سالم قبل از خرابکاری.

🎯 مسئله

اجرای بازگشت سخت و نابود کردن کامل کامیت خراب و کدهای آن.

⌨️ اقدام

git reset --hard HEAD~1

✅ دستاورد

پیام HEAD is now at... صادر شده و هم کامیت و هم کدهای آن کلاً محو شدند.

🎯 مسئله

باز کردن فایل index.html و تایید پاک شدن کامل تغییر خرابکاری.

⌨️ اقدام

فایل index.html را در VS Code ببین.

✅ دستاورد

هیچ اثری از کد خرابکاری در فایل باقی نمانده است.

⚠️ تفاوت بسیار مهم

• git reset --soft: کامیت را پاک می‌کند اما کدها را در Staging نگه می‌دارد (ایمن).
• git reset --hard: هم کامیت و هم کدهای آن را کلاً نابود می‌کند (خطرناک!).

🎯 مسئله

پیش از اجرای دستور خطرناک Hard Reset، کاتب می‌خواهد یک پشتیبان صوتی/متنی روی یک شاخه موقت بسازد تا در صورت پشیمانی، کامیت‌ها نابود نشوند.

⌨️ اقدام

یک شاخه پشتیبان بساز و سپس به main برگرد:

git branch backup-before-reset

✅ دستاورد

ایجاد یک تور ایمنی که باعث می‌شود حتی پس از reset --hard هم کدهای قدیمی از طریق شاخه backup قابل دسترسی باشند.

💡 چیستی و خطرات بازگشت سخت (git reset --hard)

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

⚠️ قانون طلایی امنیت:

هرگز از --hard استفاده نکنید مگر آنکه ۱۰۰٪ مطمئن باشید که کدهای تغییریافته کاملاً زاید و بی‌ارزش هستند و می‌خواهید پروژه به وضعیت دقیق کامیت قدیمی بازگردد.

📜 استعاره داستانی: reset --hard مانند سقوط در پرتگاه تند وادی استغناست؛ تمام نوشته‌ها نابود می‌شوند و هیچ راه بازگشتی نیست!

❓ چالش تحلیل ریسک

چرا توسعه‌دهندگان باتجربه می‌گویند دستور git reset --hard خطرناک‌ترین دستور عقب‌گرد در گیت محلی است و پیش از اجرای آن باید احتیاط کامل داشت؟

🎓 جمع‌بندی

از پرتگاه خطرناک به سلامت عبور کردیم! اکنون تفاوت ریست نرم و سخت را می‌دانی. در درس آخر روش استاندارد تیم‌ها برای لغو کامیت‌ها (revert) را یاد می‌گیریم.

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

دستور git revert بهترین و ایمن‌ترین روش برای لغو کامیت‌ها در پروژه‌های تیمی است.

🎯 مسئله

ثبت یک کامیت حاوی خبر اشتباه باز شکاری.

⌨️ اقدام

یک خط شامل <p>خبر نادرست درباره چشمه آب</p> اضافه کن و کامیت بزن:

git commit -am "خبر نادرست باز شکاری"

✅ دستاورد

کامیت اشتباه ثبت شد.

🎯 مسئله

پیدا کردن هش کامیت خبر نادرست.

⌨️ اقدام

git log --oneline

✅ دستاورد

مشاهده شناسه کامیت خبر نادرست در بالای لاگ.

🎯 مسئله

اجرای revert برای ساخت یک کامیت پادزهر و خنثی کردن تغییر.

⌨️ اقدام

git revert HEAD --no-edit

✅ دستاورد

گیت یک کامیت جدید با پیام `Revert "خبر نادرست باز شکاری"` می‌سازد و تغییرات را خنثی می‌کند.

🎯 مسئله

مشاهده اضافه شدن کامیت جدید Revert در تاریخچه بدون پاک شدن کامیت قدیمی.

⌨️ اقدام

git log --oneline

✅ دستاورد

مشاهده اینکه هم کامیت اصلی اشتباه و هم کامیت Revert در تاریخچه ثبت شده‌اند؛ تاریخچه دستکاری نشده است!

🤝 چرا Revert برای کارهای تیمی عالی است؟

در git reset تاریخچه گذشته پاک یا دستکاری می‌شود که اگر پروژه روی اینترنت یا سیستم همکاران باشد، باعث بهم‌ریختگی شدید می‌شود.

اما git revert گذشته را دست نمی‌زند؛ بلکه یک کامیت جدید در ادامه اضافه می‌کند که اثر کامیت قبلی را خنثی می‌سازد. این روش کاملاً امن و تیمی است!

🎯 مسئله

کاتب می‌خواهد یک کامیت اشتباه را revert کند اما نمی‌خواهد ویرایشگر متن تایید پیام کامیت باز شود و مایل است پیام پیش‌فرض گیت فوراً ثبت گردد.

⌨️ اقدام

پرچم --no-edit را هنگام اجرای revert وارد کن:

git revert HEAD --no-edit

✅ دستاورد

ایجاد و ثبت آنی کامیت معکوس (Revert Commit) بدون وقفه در ترمینال.

💡 چیستی و نحوه عملکرد خنثی‌سازی ایمن (git revert)

دستور git revert بر خلاف دستورات reset، تاریخچه گذشته را هیچ تغییری نمی‌دهد! بلکه یک کامیت جدید به عنوان «پادزهر» می‌سازد که دقیقاً عکسِ تغییرات کامیت قبلی را اعمال کرده و آن را خنثی می‌کند.

🌐 چرا Revert استاندارد پروژه‌های تیمی است؟

چون اگر کامیتی به سرور (مانند گیت‌هاب) ارسال شده باشد، استفاده از reset تاریخچه همکاران را خراب می‌کند. اما revert تاریخچه را حفظ کرده و لغو تغییرات را به صورت شفاف ثبت می‌نماید.

📜 استعاره داستانی: revert مانند نوشتن یک تکمله‌نامه رسمی توسط هدهد است که خبر نادرست باز را اصلاح کرده اما برگه خبر قبلی را پاره نمی‌کند.

❓ چالش سناریوی تیمی

تیم پرندگان یک کامیت اشتباهی را به گیت‌هاب push کرده‌اند. چرا هدهد از کاتب می‌خواهد که برای لغو این کامیت از git revert استفاده کند و شدیداً از git reset منع می‌نماید؟

🏆 تبریک! نشان «🎒 نشان وادی استغنا» آزاد شد

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

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

بعد از این وادیّ توحید آیدت
منزل تفرید و تجرید آیدت
روی‌ها چون زین بیابان درکنند
جمله سر از یک گریبان برکنند

هدهد فرمود: «در این منزلگاه مهم، باید سنگی گران‌بها و نشانه‌ای استوار (Tag) بر فراز کوه نصب کنیم تا این نقطه تاریخی برای همیشه ثبت شود!»

🎯 مسئله

مشاهده لاگ برای انتخاب آخرین کامیت جهت ثبت نسخه رسمی مایلستون.

⌨️ اقدام

git log --oneline

✅ دستاورد

مشاهده کامیت‌های پروژه و آمادگی برای برچسب‌گذاری.

🎯 مسئله

ساخت یک برچسب توضیحات‌دار (Annotated Tag) به نام v0.7.0 روی کامیت فعلی.

⌨️ اقدام

git tag -a v0.7.0 -m "نسخه میانی وادی توحید"

✅ دستاورد

برچسب رسمی v0.7.0 برای این نقطه زمانی پروژه متولد شد.

🎯 مسئله

مشاهده تمامی تگ‌های ثبت‌شده در مخزن پروژه.

⌨️ اقدام

git tag

✅ دستاورد

نمایش عبارت v0.7.0 در ترمینال.

🎯 مسئله

مشاهده موقعیت تگ جدید در کنار هش کامیت در تاریخچه.

⌨️ اقدام

git log --oneline --graph

✅ دستاورد

مشاهده عبارت (HEAD -> main, tag: v0.7.0) در کنار پیام کامیت.

🎯 مسئله

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

⌨️ اقدام

نام تگ را جلوی دستور show در ترمینال وارد کن:

git show v0.7.0

✅ دستاورد

نمایش شناسنامه کامل برچسب و تفاوت خطوط کامیت مربوط به آن.

💡 چیستی و ماهیت برچسب‌گذاری (Tag) در گیت

برچسب یا Tag در گیت مانند «مهر و موم و سنگ‌نوشته ثابت بر فراز یک کامیت خاص» است. بر خلاف شاخه‌ها (Branch) که متحرک بوده و با کامیت‌های جدید جلو می‌روند، تگ برای همیشه به یک کامیت مشخص قفل می‌شود.

🏷️ انواع تگ در گیت:

• Lightweight: برچسب ساده که فقط یک نام و اشاره‌گر است.
• Annotated (با پرچم -a): برچسب کامل شناسنامه‌دار که شامل نام برچسب‌زننده، ایمیل، تاریخ و پیام توضیحی است (استاندارد ریلیز پروژه مانند v1.0.0).

📜 استعاره داستانی: git tag همان سنگ‌نوشته استواری است که کاتب بر قله کوه وادی توحید نصب می‌کند تا نقطه پایانی یک منزل بزرگ برای همیشه جاودانه شود.

❓ چالش مفهوم تگ

کاتب برچسب v1.0.0 را روی آخرین کامیت شاخه main زد و سپس ۳ کامیت جدید دیگر اضافه نمود. چرا برچسب v1.0.0 همراه با کامیت‌های جدید جلو نرفت و روی کامیت قدیمی باقی ماند؟

🎓 جمع‌بندی

تبریک! با تگ‌ها می‌توانی نسخه انتشار پروژه‌ات را ثابت کنی. در درس بعدی استخراج تک‌کامیت‌ها با `git cherry-pick` را یاد می‌گیریم.

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

دستور git cherry-pick برای دست‌چین کردن دقیق یک کامیت مشخص استفاده می‌شود.

🎯 مسئله

ساخت شاخه جدید feature/hudhud-message.

⌨️ اقدام

git switch -c feature/hudhud-message

✅ دستاورد

ورود به شاخه جدید.

🎯 مسئله

افزودن پیام حکمت هدهد در index.html.

⌨️ اقدام

این عبارت را اضافه کن:

<p>حکمت هدهد: در توحید، همه راه‌ها به یک نقطه می‌رسند.</p>

✅ دستاورد

پیام آماده شد.

🎯 مسئله

کامیت کردن پیام حکمت هدهد.

⌨️ اقدام

git commit -am "پیام حکمت هدهد در وادی توحید"

✅ دستاورد

کامیت پیام ثبت گردید.

🎯 مسئله

کپی کردن هش کامیت این پیام برای استفاده در cherry-pick.

⌨️ اقدام

git log --oneline -n 1

✅ دستاورد

یادداشت کردن کد ۷ حرفی هش کامیت.

🎯 مسئله

بازگشت به شاخه اصلی main.

⌨️ اقدام

git switch main

✅ دستاورد

محیط کاری روی main قرار گرفت.

🎯 مسئله

انتقال منحصربه‌فرد همان کامیت به شاخه main بدون ادغام کامل شاخه.

⌨️ اقدام

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

git cherry-pick HEAD@{1}

✅ دستاورد

همان یک کامیت به زیبایی وارد شاخه main شد!

🎯 مسئله

دیدن تاریخچه main برای تایید انتقال دقیق همان کامیت.

⌨️ اقدام

git log --oneline -n 1

✅ دستاورد

تایید انتقال تک‌کامیت.

💡 چیستی و کارکرد دست‌چین کردن (git cherry-pick)

دستور git cherry-pick به زبان ساده یعنی «چیدن یک میوه خاص از یک درخت دیگر!». این دستور یک کامیت مشخص را از هر شاخه‌ای که باشد برمی‌دارد و دقیقاً همان تغییرات را روی شاخه فعلی شما اعمال و کامیت می‌کند.

🎯 چه زمانی به Cherry-pick نیاز داریم؟

وقتی در یک شاخه آزمایشی، کدهای فراوانی زده‌اید اما فقط یکی از کامیت‌های آن (مثلاً اصلاح یک باگ مهم) را فوراً در شاخه اصلی (main) نیاز دارید، بدون اینکه مجبور باشید کل شاخه آزمایشی را ادغام (Merge) کنید.

📜 استعاره داستانی: cherry-pick دست‌چین کردن تنها یک پرِ حاوی پیام حکمت هدهد از میان صدها پرِ شاخه دورافتاده است.

🎯 مسئله

اگر هنگام اجرا دستور git cherry-pick با تداخل کدها مواجه شویم و کاتب بخواهد عملیات دست‌چین کردن را کلاً لغو کرده و به حالت قبل برگردد چه کند؟

⌨️ اقدام

دستور زیر را در ترمینال وارد کن:

git cherry-pick --abort

✅ دستاورد

لغو کامل عملیات cherry-pick و بازگشت شاخه فعلی به حالت تمیز اولیه.

🎯 مسئله

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

⌨️ اقدام

git branch -D feature/hudhud-message

✅ دستاورد

شاخه اضافی حذف گردید.

❓ چالش سناریویی

کاتب ۱۰ کامیت در شاخه آزمایشی زده است اما فقط کامیت پنجم (با هش a1b2c3d) باید فوراً وارد شاخه اصلی main شود بدون اینکه ۹ کامیت دیگر منتقل گردند. دستور دقیق چیست؟

🎓 جمع‌بندی

بسیار عالی! با `git cherry-pick` توانستی کامیت مورد نظرت را دست‌چین کنی. در درس بعد مرتب‌سازی خطی شاخه‌ها با `git rebase` را یاد می‌گیریم.

در اوج آسمان وادی توحید، پرندگان هم‌ردیف و منظم پرواز کردند.

📖 حکایت قطره‌های باران و دریا: قطره‌های باران چون بر سطح دریا فروریختند، گسستگی و پراکندگی را رها کرده و یک‌پارچه و هموار گشتند. هدهد گفت: به جای اینکه مسیرهای پرواز مرتباً به هم بپیچند، می‌توانیم کارهای شاخه را بر پایه آخرین نسخه شاخه اصلی مرتب کنیم (git rebase) تا خط پرواز پروژه کاملاً صاف و مستقیم شود!

🌱 Merge در برابر Rebase

• git merge: دو شاخه را با ایجاد یک کامیت ادغام جدید (Merge Commit) به هم وصل می‌کند (تاریخچه غیرخطی شاخه‌ای).
• git rebase: کامیت‌های شاخه شما را برداشته و دقیقاً نوک آخرین کامیت شاخه main بازنویسی و منتقل می‌کند (تاریخچه کاملاً صاف و خطی).

🎯 مسئله

ساخت شاخه جدید feature/final-report.

⌨️ اقدام

git switch -c feature/final-report

✅ دستاورد

ورود به شاخه گزارش نهایی.

🎯 مسئله

افزودن متنی جدید در این شاخه و کامیت آن.

⌨️ اقدام

کد زیر را اضافه کن و کامیت بزن:

<p>نظم پرواز در وادی توحید حاکم است.</p>

git commit -am "افزودن متن نظم پرواز"

✅ دستاورد

کامیت ثبت گردید.

🎯 مسئله

سوییچ به main و ثبت یک کامیت جدید تا شاخه main جلوتر برود.

⌨️ اقدام

git switch main

git commit --allow-empty -m "به‌روزرسانی مستقل شاخه اصلی"

✅ دستاورد

شاخه main یک قدم جلوتر رفت.

🎯 مسئله

بازگشت به شاخه feature/final-report برای اجرای rebase.

⌨️ اقدام

git switch feature/final-report

✅ دستاورد

آمادگی برای انتقال مبنا به نوک شاخه main.

🎯 مسئله

انتقال مبنای شاخه فعلی به نوک شاخه main با git rebase.

⌨️ اقدام

git rebase main

✅ دستاورد

پیام Successfully rebased and updated صادر شد.

💡 چیستی و نحوه عملکرد انتقال مبنا (git rebase)

دستور git rebase main کلمه Re-base یعنی «تغییر دادن پایه و مبنای شاخه». این دستور تمام کامیت‌های شاخه شما را موقتاً کنار می‌گذارد، پایه شاخه شما را به نوکِ آخرین کامیت شاخه main منتقل کرده و سپس کامیت‌های شما را یکی‌یکی روی آن بازنویسی می‌کند.

✨ نتیجه شگفت‌انگیز Rebase:

تاریخچه پروژه به یک خط کاملاً مستقیم و صاف (Linear History) تبدیل می‌شود و دیگر خبری از حباب‌ها و کامیت‌های ادغام شلوغ (Merge Commits) نخواهد بود.

📜 استعاره داستانی: rebase هم‌ردیف شدن و پرواز قطره‌های باران بر سطح دریاست تا گسستگی را رها کرده و یکپارچه شوند.

🎯 مسئله

مشاهده تاریخچه گرافیکی کاملاً خطی و مستقیم.

⌨️ اقدام

git log --graph --oneline

✅ دستاورد

تاریخچه به یک خط مستقیم بدون هیچ شاخ‌وبرگ اضافی تبدیل شده است!

🎯 مسئله

ادغام به روش Fast-Forward روی main.

⌨️ اقدام

git switch main
git merge feature/final-report

✅ دستاورد

ادغام سریع و پاک بدون ساخت کامیت اضافی انجام گرفت.

🚨 قانون طلایی Rebase

هرگز کامیت‌هایی که قبلاً روی یک مخزن عمومی مشترک (مانند گیت‌هاب) Push شده‌اند را Rebase نکنید!

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

🎯 مسئله

اگر در حین بازنویسی تاریخچه خطی با git rebase تداخل غیرمنتظره‌ای پیش آید، کاتب چگونه می‌تواند تمام عملیات rebase را فوراً لغو کند؟

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

git rebase --abort

✅ دستاورد

توقف و انصراف کامل از rebase و خروج امن از فرآیند بازنویسی تاریخچه.

🚨 چیستی قانون طلایی Rebase (Golden Rule of Rebase)

قانون طلایی گیت می‌گوید: «هرگز شاخه‌ای را که عمومی شده و دیگران از آن استفاده می‌کنند، Rebase نکنید!»

⚠️ دلیل فنی:

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

📜 استعاره داستانی: نظم پرواز کاروان در وادی توحید نباید با تغییر مسیرهای اعلان‌شده همکاران دچار اغتشاش شود.

❓ چالش قانون طلایی Rebase

مهم‌ترین «قانون طلایی Rebase» چیست و چرا نباید شاخه‌هایی که قبلاً روی گیت‌هاب عمومی push شده‌اند را rebase کرد؟

🏆 تبریک! نشان «🔗 نشان وادی توحید» آزاد شد

عالی بود ای کاتب هوشمند! با موفقیت بر مفاهیم Tag، Cherry-pick و Rebase مسلط شدی و نشان وادی توحید را از آن خود کردی. در فصل بعد وارد **وادی حیرت** (اتصال به ابر و گیت‌هاب) می‌شویم...

کاروان پرندگان وارد ششمین وادی حیرت‌انگیز یعنی وادی حیرت گردید. وادی حیرت، دشت سرگشتگی و شگفتی در برابر عظمت بی‌کران است.

بعد از این وادیّ حیرت آیدت
کار هر لحظه چو حسرت آیدت
حیرت آمد کفر بود و دین نماند
در دل حیرت گم و مسکین نماند

📖 حکایت نگریستن به ستاره‌ها در آشیانه ابری: سالکی در شب تاریک چشم بر آسمان بی‌انتها دوخت و از تکثر نور ستاره‌ها در حیرت فرو رفت. هدهد رو به آسمان کرد و گفت: «ای کاتب! وقت آن رسیده تا آشیانه‌ای ابری (Remote) بر فراز گیت‌هاب بسازیم تا دفتر کاروان از هر خطری در امان بماند!»

💻 مخزن محلی (Local) در برابر ☁️ مخزن ابری (Remote)

• Local Repository: پوشه پروژه و دیتابیس `.git` روی رایانه شخصی شما.
• Remote Repository: نسخه‌ای از مخزن پروژه شما که روی سرورهای ابری (مانند GitHub یا GitLab) میزبانی می‌شود.

مخزن ابری باعث می‌شود کدهای شما همیشه پشتیبان‌گیری شده و امکان همکاری با دیگران فراهم گردد.

🎯 مسئله

ایجاد یک آشیانه جدید و خالی در سایت GitHub.

⌨️ اقدام

وارد حساب گیت‌هاب شو، روی دکمه New Repository کلیک کن، نام آن را simorgh-journey بگذار و بدون افزودن README دکمه Create را بزن.

✅ دستاورد

یک آدرس اینترنتی (URL) اختصاصی مانند https://github.com/username/simorgh-journey.git دریافت می‌کنی.

🎯 مسئله

اتصال مخزن محلی روی سیستم به مخزن ابری گیت‌هاب با نام مستعار `origin`.

⌨️ اقدام

دستور زیر را با آدرس ریپازیتوری خودت اجرا کن:

git remote add origin https://github.com/username/simorgh-journey.git

✅ دستاورد

پل ارتباطی بین رایانه شما و آشیانه ابری گیت‌هاب برقرار شد.

🎯 مسئله

استعلام آدرس‌های اتصال به مخزن ابری برای اطمینان از صحت لینک.

⌨️ اقدام

git remote -v

✅ دستاورد

مشاهده دو آدرس fetch و push که به نام origin ثبت شده‌اند.

🎯 مسئله

اگر کاتب آدرس URL مخزن گیت‌هاب را اشتباهاً تایپ کرده باشد یا نام ریپازیتوری روی گیت‌هاب تغییر کند، چگونه آدرس ریموت origin را اصلاح نماید؟

⌨️ اقدام

دستور زیر را با آدرس جدید اجرا کن:

git remote set-url origin https://github.com/username/new-simorgh-journey.git

✅ دستاورد

به‌روزرسانی سریع آدرس اتصال ریموت origin که با اجرای git remote -v تایید می‌شود.

💡 چیستی و ماهیت مخزن ابری (git remote)

دستور git remote پل ارتباطی پروژه محلی شما به سرورهای ابری (مانند GitHub یا GitLab) است. کلمه origin نام مستعار استاندارد و قراردادی است که به سرور اصلی پروژه داده می‌شود.

💻 Local در برابر ☁️ Remote:

• Local: تمام کدهایی که روی سیستم خودتان است و فقط خودتان به آن‌ها دسترسی دارید.
• Remote: نسخه‌ای که روی ابر قرار دارد و همکاران می‌توانند آن را ببینند و کدهای خود را به آن پیوند دهند.

📜 استعاره داستانی: git remote ساختن آشیانه‌ای بلورین بر فراز ابرهای وادی حیرت است تا نوشته‌های دفتر سفر از آتش و طوفان‌های زمین در امان بمانند.

📥 fetch و 📤 push چیستند؟

• (fetch): آدرسی که گیت از آن کدهای جدید را از سرور دانلود می‌کند.
• (push): آدرسی که گیت کدهای محلی شما را به آن آپلود و ارسال می‌کند.

نام origin نام قراردادی و استاندارد برای سرور اصلی پروژه است.

❓ چالش درک مفاهیم

کاتب مخزن محلی پروژه را روی سیستمش ساخته است. او می‌خواهد کدهایش را روی گیت‌هاب بگذارد. عبارت origin در دستور git remote add origin https://... چه نقشی ایفا می‌کند؟

🎓 جمع‌بندی

عالی بود! پل ارتباطی برقرار شد. در درس بعد اولین پرواز کدهای کاروان به سوی ابر (Push) را انجام خواهیم داد.

با برقرار شدن پل ارتباطی، پرنده نامه‌رسان بال‌هایش را گشود تا اولین نسخه از دفتر سفر را به آشیانه ابری گیت‌هاب بفرستد. هدهد گفت: «ارسال کدهای محلی به سرور ابری را Push (فرستادن) می‌نامند!»

🎯 مسئله

اطمینان از کامیت شدن تمام تغییرات پیش از ارسال به گیت‌هاب.

⌨️ اقدام

git status

✅ دستاورد

تایید تمیز بودن محیط کار برای ارسال.

🎯 مسئله

اولین ارسال کامیت‌ها به سرور ابری به همراه تنظیم شاخه پیگیری‌کننده (Upstream).

⌨️ اقدام

git push -u origin main

✅ دستاورد

ارسال کامیت‌ها و نمایش پیام Branch 'main' set up to track remote branch 'main' from 'origin'.

🎯 مسئله

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

⌨️ اقدام

صفحه وب ریپازیتوری خود در گیت‌هاب را رفرش کن.

✅ دستاورد

مشاهده تمام فایل‌ها، خطوط کد و تاریخچه کامیت‌ها در سایت گیت‌هاب!

💡 چیستی و عملکرد ارسال کدهای ابری (git push)

دستور git push تمام کامیت‌ها، عکس‌های تاریخی و شاخه‌های ثبت‌شده در سیستم محلی شما را به مخزن ابری origin در گیت‌هاب آپلود می‌کند.

🔑 پرچم -u (--set-upstream) چیست؟

در اولین push، با زدن git push -u origin main گیت یک پیوند پیگیری دائمی بین شاخه main محلی و main ابری می‌سازد. از دفعات بعدی، فقط نوشتن دستور git push به تنهایی کافی خواهد بود!

📜 استعاره داستانی: git push پرواز پرنده نامه‌رسان برای رساندن برگه‌های جدید دفتر کاتب به آشیانه ابری است.

🎯 مسئله

ایجاد یک ویرایش جدید در index.html برای تست ارسال ساده بعدی.

⌨️ اقدام

یک متن جدید اضافه کن و کامیت کن:

git commit -am "ورود به آسمان ابری وادی حیرت"

✅ دستاورد

کامیت جدید به صورت محلی ثبت شد.

🎯 مسئله

ارسال کامیت‌های جدید به گیت‌هاب (حالا به دلیل وجود `-u` قبلی، فقط با `git push` نیز کار می‌کند!).

⌨️ اقدام

git push

✅ دستاورد

کامیت‌های تازه به سرور ابری منتقل شدند.

🎯 مسئله

کاتب یک شاخه جدید به نام feature/story محلی ساخته است و می‌خواهد دقیقاً همین شاخه را روی سرور ابری گیت‌هاب ارسال (Push) کند.

⌨️ اقدام

نام شاخه را همراه با پرچم -u تایپ کن:

git push -u origin feature/story

✅ دستاورد

ساخته شدن شاخه هم‌نام جدید روی سرور ابری گیت‌هاب همراه با پیوند پیگیری Upstream.

🎯 مسئله

چک کردن اضافه شدن کامیت در لیست Commits سایت گیت‌هاب.

⌨️ اقدام

بخش Commits در گیت‌هاب را باز کن.

✅ دستاورد

تایید وجود کامیت جدید در گیت‌هاب.

❓ چالش تحلیل عملکرد -u

کاتب در اولین ارسال دستور git push -u origin main را اجرا نمود. از دفعه دوم به بعد، او فقط git push را به تنهایی تایپ می‌کند. پرچم -u در نوبت اول چه کاری انجام داده بود؟

🎓 جمع‌بندی

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

پرنده‌ای نامه‌رسان از آشیانه ابری برگشت و گفت: «خبرهایی تازه در سرور ابری ثبت شده است!» هدهد گفت: «پیش از آنکه کدهای ابری را وارد دفتر محلی خود کنی، ابتدا با دستور git fetch اطلاعات را استعلام کن تا ببینی چه تغییراتی ایجاد شده است بدون اینکه فایل‌هایت دست بخورند!»

🎯 مسئله

ساخت یک تغییر مستقیم روی گیت‌هاب (مانند ویرایش فایل روی سایت یا کامیت همکار).

⌨️ اقدام

روی سایت گیت‌هاب فایل index.html را باز کن، دکمه ویرایش (آیکون مداد) را بزن، یک خط اضافه کن و دکمه Commit changes را بزن.

✅ دستاورد

نسخه ابری ۱ کامیت از نسخه محلی شما جلوتر افتاد!

🎯 مسئله

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

⌨️ اقدام

git fetch

✅ دستاورد

گیت اطلاعات آخرین تغییرات را دانلود کرد اما کدهای شما روی هارد دیسک هنوز دست‌نخورده‌اند.

🎯 مسئله

باز کردن فایل index.html در VS Code و تایید عدم تغییر مستقیم آن.

⌨️ اقدام

فایل index.html در VS Code را ببین.

✅ دستاورد

تایید اینکه `git fetch` کدهای محلی شما را دستکاری نمی‌کند.

🎯 مسئله

مشاهده تفاوت کدهای محلی (main) با کدهای دریافت شده از ابری (origin/main).

⌨️ اقدام

git diff main origin/main

✅ دستاورد

دیدن دقیق خطوطی که روی گیت‌هاب اضافه شده‌اند قبل از ادغام آنها!

🎯 مسئله

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

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

git fetch --all

✅ دستاورد

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

💡 چیستی و امنیت دستور git fetch

دستور git fetch تمام اخبار، تغییرات و کامیت‌های جدید سرور ابری را دانلود می‌کند، اما هیچ تغییری روی کدهای فعال شما (Working Directory) ایجاد نمی‌کند!

🔍 چرا fetch بسیار امن است؟

چون به شما امکان می‌دهد ابتدا با دستوراتی مانند git diff main origin/main کدهای جدید همکاران یا سرور را زیر ذره‌بین بررسی کنید و پس از اطمینان، آن‌ها را ادغام نمایید.

📜 استعاره داستانی: git fetch شنیدن کلام پیکِ رسیده از ابر است بدون اینکه هنوز آن کلام را در برگه اصلی دفتر کاتب وارد کرده باشیم.

❓ چالش سناریویی دانلود امن

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

🎓 جمع‌بندی

بسیار عالی! اکنون می‌دانی چگونه بدون ریسک، اخبار سرور ابری را چک کنی. در درس بعد همگام‌سازی کامل با `git pull` را یاد می‌گیریم.

پس از آنکه تغییرات سرور ابری را بررسی کردیم، هدهد فرمود: «پیام ابری بسیار ارزشمند است؛ آن را وارد دفتر کن!»

برای دریافت و ادغام یکباره آخرین کدهای گیت‌هاب روی سیستم محلی از دستور git pull استفاده می‌کنیم.

🎯 مسئله

همگام‌سازی مستقیم و دریافت آخرین کامیت‌های گیت‌هاب روی رایانه.

⌨️ اقدام

git pull

✅ دستاورد

پیام Updating ... Fast-forward صادر شده و تغییرات ابری مستقیماً وارد فایل محلی شدند.

🎯 مسئله

مشاهده خطوط جدید اضافه شده در فایل index.html.

⌨️ اقدام

فایل index.html را در VS Code ببین.

✅ دستاورد

تغییری که روی سایت گیت‌هاب داده بودید، حالا در سیستم محلی شما حاضر است!

🎯 مسئله

دیدن تاریخچه لاگ جهت تایید ثبت کامیت ابری در سیستم محلی.

⌨️ اقدام

git log --oneline -n 2

✅ دستاورد

مشاهده کامیت دریافت‌شده در بالای تاریخچه.

🎯 مسئله

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

⌨️ اقدام

پرچم --rebase را هنگام pull اضافه کن:

git pull --rebase origin main

✅ دستاورد

همگام‌سازی تمیز و خطی کدهای محلی با سرور ابری بدون ایجاد Merge Commit زاید.

💡 چیستی و فرمول ترکیبی git pull

دستور git pull ابزار همگام‌سازی مستقیم است. این دستور تغییرات جدید را از سرور ابری دانلود کرده و فوراً با کدهای محلی شما ادغام می‌نماید.

🧮 فرمول طلایی:

git pull = git fetch + git merge

اگر می‌خواهید بدون تشریفات بررسی، آخرین کدهای گیت‌هاب فوراً روی کدهای شما بنشیند، از git pull استفاده کنید.

📜 استعاره داستانی: git pull وارد ساختن مستقیم نغمه جدید آشیانه ابری به متن اصلی دفتر کاتب است.

💡 فرمول طلایی git pull

به همین سادگی:

git pull = git fetch + git merge

دستور git pull ابتدا اطلاعات را fetch می‌کند و بلافاصله آن را با شاخه فعلی شما merge می‌نماید.

❓ چالش فرمول عملکرد pull

دستور git pull در باطن خود حاصل فرمول ترکیبی کدام دو دستور پایه گیت است و چه عملی انجام می‌دهد؟

🎓 جمع‌بندی

عالی بود! سیستم محلی و ابری کاملاً همگام شدند. در درس آخر تکثیر کامل پروژه روی رایانه‌های دیگر با `git clone` را یاد می‌گیریم.

تصور کن می‌خواهی پروژه را روی رایانه جدیدی در سرزمینی دیگر دانلود کنی یا یکی از پرندگان جدید کاروان می‌خواهد کل دفتر سفر را با تمامی گذشته‌اش داشته باشد. هدهد گفت: «در گیت، به این کار Clone (همزادسازی/تکثیر) می‌گویند!»

🎯 مسئله

باز کردن یک پنجره جدید ترمینال در یک پوشه آزمایشی مجزا.

⌨️ اقدام

یک پوشه جدید به اسم test-clone روی سیستم بساز و در ترمینال وارد آن شو.

✅ دستاورد

محیط خالی آماده دانلود پروژه شد.

🎯 مسئله

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

⌨️ اقدام

دستور زیر را با آدرس گیت‌هاب پروژه اجرا کن:

git clone https://github.com/username/simorgh-journey.git

✅ دستاورد

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

🎯 مسئله

کاتب می‌خواهد پروژه را از گیت‌هاب clone کند، اما می‌خواهد اسم پوشه ایجادشده روی رایانه نام دلخواه my-simorgh-app باشد.

⌨️ اقدام

نام پوشه دلخواه را در انتهای دستور clone اضافه کن:

git clone https://github.com/username/simorgh-journey.git my-simorgh-app

✅ دستاورد

دانلود پروژه گیت‌هاب درون پوشه‌ای به نام سفارشی my-simorgh-app روی دیسک.

🎯 مسئله

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

⌨️ اقدام

پوشه `simorgh-journey` جدید را در VS Code باز کن.

✅ دستاورد

مشاهده تمامی فایل‌ها در سلامت کامل.

🎯 مسئله

بررسی اینکه آیا تمام تاریخچه گذشته پروژه نیز منتقل شده است یا خیر.

⌨️ اقدام

git log --oneline

✅ دستاورد

مشاهده تمامی کامیت‌های از روز اول پروژه تا به امروز!

🎯 مسئله

تایید اینکه `git clone` به صورت خودکار آدرس `origin` را هم تنظیم کرده است.

⌨️ اقدام

git remote -v

✅ دستاورد

آدرس‌های origin به صورت آماده تنظیم شده‌اند بدون اینکه نیاز به اجرا مجدد `git remote add` باشد!

💡 چیستی و قدرت تکثیر پروژه (git clone)

دستور git clone تمام کدهای یک ریپازیتوری، کامل‌ترین تاریخچه کامیت‌ها از روز اول، همه شاخه‌ها و پوشه مخفی .git را از سرور ابری دانلود کرده و ریموت origin را به صورت خودکار تنظیم می‌کند.

📦 تفاوت تفاوت با دانلود ZIP:

فایل ZIP مرده است! چون هیچ پوشه `.git` و تاریخچه‌ای ندارد. اما git clone یک پروژه زنده و فعالِ گیت تحویل شما می‌دهد که آماده توسعه، کامیت و push مجدد است.

📜 استعاره داستانی: git clone خلق آینه‌ای کاملاً همزاد و دقیق از دفتر سفر در دست کاتبی جدید در سرزمینی دیگر است.

📦 چرا دانلود ZIP فایده‌ای ندارد؟

اگر پروژه را به صورت ZIP دانلود کنید، فقط آخرین نسخه فایل‌ها بدون پوشه `.git` دانلود می‌شود؛ یعنی تمام تاریخچه کامیت‌ها، شاخه‌ها و ارتباط با سرور کلاً نابود می‌شود!

اما با git clone، تمام تاریخچه، شاخه‌ها و اتصالات به صورت یک پروژه زنده گیت دریافت می‌شوند.

❓ چالش مقایسه clone با دانلود ZIP

کاتب می‌خواهد پروژه‌ای را از گیت‌هاب بگیرد. دوستش دانلود فایل ZIP را پیشنهاد می‌کند اما هدهد اصرار بر git clone دارد. تفاوت حیاتی git clone با دانلود فایل ZIP چیست؟

🏆 تبریک! نشان «☁️ نشان وادی حیرت» آزاد شد

شاهکار کردی ای کاتب ابری! اکنون بر تمام ابزارهای کار با گیت‌هاب (remote, push, fetch, pull, clone) تسلط کامل داری. نشان وادی حیرت از آن توست! در فصل آخر وارد **وادی فقر و فنا** (کار تیمی، Fork و PR) می‌شویم...

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

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

هدهد فرمود: «هر پرنده‌ای که می‌خواهد در تکمیل این دفتر تاریخی مشارکت کند، ابتدا باید یک نسخه شخصی (Fork) از مخزن اصلی در اکانت گیت‌هاب خود بسازد!»

🍴 فورک (Fork) چیست؟

فورک کپی مستقل از یک ریپازیتوری روی اکانت گیت‌هاب شخصی شماست. در دنیای متن‌باز (Open Source)، شما دسترسی مستقیم برای دستکاری ریپازیتوری اصلی دیگران ندارید، بنابراین ابتدا آن را Fork می‌کنید، تغییرات را در نسخه شخصی خود انجام داده و سپس پیشنهاد ادغام می‌دهید.

🎯 مسئله

ساخت نسخه کپی شخصی از یک ریپازیتوری عمومی روی اکانت گیت‌هاب خود.

⌨️ اقدام

وارد صفحه ریپازیتوری اصلی شو و در بالای سمت راست روی دکمه Fork کلیک کن.

✅ دستاورد

ریپازیتوری جدیدی به نام `username/simorgh-journey` در اکانت شخصی شما ساخته می‌شود.

🎯 مسئله

دانلود نسخه Forkشده شخصی روی سیستم محلی.

⌨️ اقدام

git clone https://github.com/your-username/simorgh-journey.git

✅ دستاورد

دانلود کدهای نسخه اختصاصی شما روی رایانه.

🎯 مسئله

استعلام آدرس origin برای تایید اتصال به فورک شخصی.

⌨️ اقدام

git remote -v

✅ دستاورد

مشاهده آدرس اکانت شخصی شما جلوی origin.

🎯 مسئله

کاتب پروژه اصلی را Fork کرده و آدرس origin به فورک شخصی خودش متصل است؛ حالا چگونه آدرس پروژه اصلی را تحت نام مستعار upstream اضافه کند تا بتواند بعداً کدهای خود را با اصلی همگام نگه دارد؟

⌨️ اقدام

دستور زیر را با آدرس مخزن اصلی پروژه اجرا کن:

git remote add upstream https://github.com/original-owner/simorgh-journey.git

✅ دستاورد

اضافه شدن اتصال upstream به لیست ریموت‌ها که با git remote -v قابل مشاهده است.

💡 چیستی و ضرورت فورک (Fork) در متن‌باز

کلمه Fork در گیت‌هاب به معنای «انشعاب و کپی کردن کامل یک ریپازیتوری عمومی روی اکانت شخصی شما» است.

🔑 چرا به Fork نیاز داریم؟

در دنیای نرم‌افزار آزاد، شما اجازه ندارید مستقیم روی پروژه‌های بزرگ دیگران (مانند React یا Vue) دستور Push بزنید. بنابراین ابتدا پروژه آن‌ها را Fork می‌کنید تا صاحب کپیِ اختصاصی خود شوید، در آن کد بزنید و سپس پیشنهاد ادغام دهید.

📜 استعاره داستانی: Fork ساختن نسخه شخصی از دفتر سفر کاروان در دست هر پرنده است تا بدون بهم ریختن دفتر اصلی، سهم خود را بنویسد.

🔺 مثلث کپی‌برداری در گیت

• Fork: کپی ابری در سطح اکانت گیت‌هاب.
• Clone: کپی محلی روی رایانه شخصی.
• Branch: خط زمانی موازی در داخل یک ریپازیتوری.

❓ چالش سناریویی متن‌باز

کاتب می‌خواهد در توسعه یک کتابخانه معروف روی گیت‌هاب که دسترسی مستقیم (Write access) به آن ندارد مشارکت کند. او چگونه می‌تواند بدون دسترسی مستقیم، کدهایش را توسعه دهد و پیشنهاد ادغام بدهد؟

🎓 جمع‌بندی

عالی بود! حالا دفتر اختصاصی خودت را داری. در درس بعدی ارسال درخواست ادغام (Pull Request) به پروژه اصلی را یاد می‌گیریم.

سی‌امین پرنده نیز به قله قاف رسید و نامش به فهرست اضافه شد. او می‌خواهد نام خود را به دفتر اصلی کاروان پیشنهاد دهد. هدهد گفت: «در گیت‌هاب، پیشنهاد ادغام کد از نسخه شخصی به پروژه اصلی را Pull Request (PR) می‌نامند!»

🎯 مسئله

ایجاد یک شاخه جدید در فورک شخصی برای اعمال تغییرات PR.

⌨️ اقدام

git switch -c feature/30th-bird

✅ دستاورد

ورود به شاخه اختصاصی جدید.

🎯 مسئله

اضافه کردن نام پرنده سی‌ام به فهرست در index.html.

⌨️ اقدام

کد زیر را به لیست پرندگان اضافه کن:

<li>پرنده سی‌ام (سالک قله قاف)</li>

✅ دستاورد

نام پرنده اضافه شد.

🎯 مسئله

ثبت کامیت تغییرات.

⌨️ اقدام

git commit -am "افزودن نام پرنده سی‌ام به فهرست کاروان"

✅ دستاورد

کامیت ثبت گردید.

🎯 مسئله

پوش کردن شاخه به فورک شخصی در گیت‌هاب.

⌨️ اقدام

git push -u origin feature/30th-bird

✅ دستاورد

شاخه به فورک شما روی گیت‌هاب منتقل گشت.

🎯 مسئله

کلیک روی دکمه Compare & pull request در گیت‌هاب.

⌨️ اقدام

وارد سایت گیت‌هاب شو و دکمه سبز Compare & pull request را بزن.

✅ دستاورد

فرم ساخت Pull Request باز می‌شود.

🎯 مسئله

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

⌨️ اقدام

عنوان زیر را وارد کن:

feat: افزودن مشخصات پرنده ۳۰‌ام به فهرست نهایی

✅ دستاورد

عنوان مشخص گردید.

🎯 مسئله

نوشتن توضیحات کامل (Body) در کادر PR جهت راهنمایی مدیر پروژه.

⌨️ اقدام

توضیح دهید چه تغییراتی داده‌اید و چگونه باید تست شود، سپس دکمه Create pull request را بزنید.

✅ دستاورد

Pull Request رسمی شما برای صاحبان پروژه اصلی فرستاده شد!

🎯 مسئله

کاتب می‌خواهد قبل از ارسال Pull Request، آخرین کدهای جدید پروژه اصلی (upstream) را دریافت و فورک شخصی خود را به‌روز نگه دارد.

⌨️ اقدام

دستور زیر را در ترمینال اجرا کن:

git fetch upstream
git merge upstream/main

✅ دستاورد

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

💡 چیستی و ماهیت Pull Request (PR)

درخواست ادغام یا Pull Request (PR) یعنی «پیشنهاد رسمی و محترمانه به مدیران پروژه برای کشیدن و ادغام کدهای شما در مخزن اصلی».

🎯 اجزای یک PR استاندارد:

• عنوان روشن (Title): بیان خلاصه هدف کدهای جدید (مثلا feat: افزودن دکمه ورود).
• توضیحات مفصل (Body): شرح تغییرات داده شده و روش تست برای بازبین‌ها.
• به‌روزرسانی زنده: هر کامیت جدیدی که روی آن شاخه push کنید، خودکار به این PR افزوده می‌شود.

📜 استعاره داستانی: PR تقدیم کردن برگه نوشته‌شده پرنده سی‌ام به شورای هدهد جهت اجازه ورود به دفتر اصلی سیمرغ است.

❓ چالش رفتار پویای PR

کاتب یک Pull Request روی گیت‌هاب ساخته است. اگر او پس از ساخت PR، دو کامیت جدید دیگر هم به همان شاخه شخصی push کند، چه اتفاقی برای PR باز شده روی گیت‌هاب می‌افتد؟

🎓 جمع‌بندی

آفرین! اولین PR حرفه‌ای خودت را ساختی. در درس بعدی نحوه بررسی کدهای دیگران (Code Review) را می‌آموزی.

شورای پرندگان دور هم گرد آمدند تا درخواست ادغام (PR) را بررسی کنند. هدهد گفت: «هیچ کدی نباید بدون بازبینی (Code Review) وارد شاخه اصلی پروژه شود! ما خط‌به‌خط تغییرات را می‌خوانیم، اگر نیازی به اصلاح بود تذکر می‌دهیم و پس از تایید آن را ادغام می‌کنیم.»

🎯 مسئله

دیدن تفاوت‌های کدهای پیشنهادی در صفحه PR.

⌨️ اقدام

در صفحه PR روی تب Files changed کلیک کن.

✅ دستاورد

نمایش کدهای اضافه و کم‌شده با رنگ سبز و قرمز.

🎯 مسئله

بررسی دقیق کدهای پیشنهادی جهت اطمینان از عدم وجود خطا.

⌨️ اقدام

خطوط کد را اسکرول کرده و مرور کن.

✅ دستاورد

بازبینی کدها انجام گردید.

🎯 مسئله

نوشتن نظر روی یک خط مشخص از کد.

⌨️ اقدام

ماوس را روی خط کد ببر، روی علامت پلاس (+) آبی کلیک کن و نظرت را بنویس.

✅ دستاورد

کامنت روی خط ثبت شد.

🎯 مسئله

ارسال ثبت نهایی مرور با گزینه Request changes برای اصلاح کدها.

⌨️ اقدام

دکمه Review changes را بزن، گزینه Request changes را انتخاب کرده و ثبت کن.

✅ دستاورد

درخواست اصلاح برای نویسنده PR ارسال شد.

🎯 مسئله

اصلاح کدها روی سیستم محلی در همان شاخه `feature/30th-bird`.

⌨️ اقدام

ایراد کد را در VS Code برطرف کن.

✅ دستاورد

ایراد اصلاح شد.

🎯 مسئله

کامیت و پوش مجدد اصلاحات.

⌨️ اقدام

git commit -am "fix: اصلاح ایراد مطرح شده در بازبینی"

git push

✅ دستاورد

به صورت خودکار و جادویی، این کامیت جدید به همان Pull Request قبلی در گیت‌هاب اضافه می‌شود!

🎯 مسئله

مشاهده به روزرسانی زنده PR در گیت‌هاب.

⌨️ اقدام

صفحه PR را رفرش کن.

✅ دستاورد

تایید به روزرسانی اتوماتیک PR بدون نیاز به ساخت PR جدید.

🎯 مسئله

تایید نهایی PR با گزینه Approve.

⌨️ اقدام

دکمه Review changes را بزن و گزینه Approve را انتخاب کن.

✅ دستاورد

چراغ سبز برای ادغام کدها روشن شد.

🎯 مسئله

کلیک روی دکمه ادغام اصلی (Merge pull request).

⌨️ اقدام

روی دکمه سبز Merge pull request و سپس Confirm merge کلیک کن.

✅ دستاورد

کدهای پرنده سی‌ام رسماً وارد پروژه اصلی کاروان گردید!

🎯 مسئله

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

⌨️ اقدام

دستور fetch شاخه ریموت را اجرا کن:

git fetch origin feature/30th-bird
git switch feature/30th-bird

✅ دستاورد

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

💡 چیستی و اهمیت بازبینی کد (Code Review)

بازبینی کد یا Code Review خط مقدمِ حفظ کیفیت در تیم‌های مهندسی پیشرفته است. هیچ کدی نباید مستقیماً بدون خوانده شدن توسط حداقل یک همکار وارد شاخه main شود.

🚦 سه حالت تصمیم‌گیری در Code Review:

• Comment: ثبت پرسش یا نظر بدون تایید یا رد.
• Request changes: درخواست الزامی برای اصلاح خطاهای دیده شده پیش از ادغام.
• Approve: تایید رسمی و دادن مجوز ادغام PR.

📜 استعاره داستانی: Code Review نشستن شورای سی پرنده دور یک میز جهت خواندن و تصحیح نوشته‌های یکدیگر است.

❓ چالش سناریویی Code Review

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

🎓 جمع‌بندی

فوق‌العاده بود! فرآیند کامل Code Review را آموختی. در درس بعد معماری استانداردهای تیمی Git Flow را مرور می‌کنیم.

هدهد به ۳۰ پرنده نگریست که اکنون همگی با هم کد می‌زنند. برای اینکه نظم کاروان حفظ شود، یک ساختار شاخه‌بندی استاندارد بین‌المللی به نام Git Flow معرفی کرد!

🌐 معماری Git Flow

• main: کد نهایی، پایدار و منتشرشده برای کاربران.
• develop: شاخه اصلی تست و ادغام کدهای تیم در حال توسعه.
• feature/*: شاخه‌های کوتاه‌مدت برای توسعه یک ویژگی خاص.

🎯 مسئله

ساخت شاخه اصلی توسعه `develop`.

⌨️ اقدام

git switch -c develop

✅ دستاورد

شاخه develop متولد شد.

🎯 مسئله

ساخت شاخه ویژگی جدید از روی develop.

⌨️ اقدام

git switch -c feature/simorgh-quote

✅ دستاورد

شاخه فیچر ساخته شد.

🎯 مسئله

کدنویسی ویژگی جدید و کامیت آن.

⌨️ اقدام

شعر عطار را به index.html اضافه کن و کامیت بزن:

git commit -am "feat: افزودن بیت حکمت عطار"

✅ دستاورد

ویژگی ثبت شد.

🎯 مسئله

ادغام شاخه فیچر درون develop.

⌨️ اقدام

git switch develop
git merge feature/simorgh-quote

✅ دستاورد

ویژگی جدید وارد develop شد.

🎯 مسئله

تست و اطمینان از سلامت کدهای develop.

⌨️ اقدام

git status

✅ دستاورد

تایید سلامت کدهای develop.

🎯 مسئله

انتقال کدهای تست‌شده از develop به main برای انتشار عمومی.

⌨️ اقدام

git switch main
git merge develop

✅ دستاورد

شاخه main به روزرسانی گشت.

🎯 مسئله

تمیز کردن شاخه‌های کامل‌شده.

⌨️ اقدام

git branch -d feature/simorgh-quote

✅ دستاورد

پاک‌سازی محیط کاری.

🎯 مسئله

در معماری Git Flow اگر یک باگ امنیتی فوری در محیط زنده (main) کشف شود، کاتب چگونه شاخه اصلاح فوری (hotfix) بسازد؟

⌨️ اقدام

مستقیماً از روی شاخه main شاخه جدید بساز:

git switch main
git switch -c hotfix/security-fix

✅ دستاورد

ساخت شاخه اصلاح اضطراری آماده کدنویسی بدون تداخل با کدهای در حال توسعه develop.

💡 چیستی و معماری شاخه‌بندی Git Flow

الگوی Git Flow یک استاندارد معماری تیمی برای مدیریت شاخه‌ها در پروژه‌های بزرگ است تا از تداخل کدها جلوگیری شود.

🌳 شاخه‌های اصلی در Git Flow:

• main: کد نهایی، پاک و بدون باگ که دست کاربران واقعی است.
• develop: قلب توسعه تیمی؛ تمام ویژگی‌های جدید پس از ساخت ابتدا اینجا ادغام می‌شوند.
• feature/*: شاخه‌های موقت توسعه کارهای فردی که از develop جدا می‌شوند.

📜 استعاره داستانی: Git Flow فرمول آرایش پرواز دسته‌جمعی پرندگان در وادی فقر و فناست تا هیچ دو پرنده‌ای به بال‌های هم برخورد نکنند.

❓ چالش معماری Git Flow

در استاندارد معماری تیمی Git Flow، نقش حیاتی شاخه main و شاخه develop چیست و چرا کدهای جدید مستقیماً روی main ادغام نمی‌شوند؟

🎓 جمع‌بندی

بسیار عالی! اکنون با الگوی Git Flow مانند مهندسان ارشد نرم‌افزار کد می‌زنی. در درس بعدی راز نهایی آینه سیمرغ را فاش می‌کنیم.

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

چون نگه کردند آن سی مرغ زود
بی‌شک این سی مرغ آن سیمرغ بود
خویش را دیدند سیمرغ تمام
بود خود سیمرغ، سی مرغ تمام

🎯 مسئله

افزودن بخش باشکوه راز سیمرغ به انتهای فایل index.html.

⌨️ اقدام

کد زیر را اضافه کن:

<h1 style="color: #8b5cf6; text-align: center;">✨ راز سیمرغ فاش شد ✨</h1>
<p style="text-align: center; font-size: 1.2rem;">سی مرغ سالک، خود سیمرغ پادشاه بودند.</p>

✅ دستاورد

شاهکار داستان کامل شد.

🎯 مسئله

تماشای نتیجه نهایی وب‌سایت حماسی سیمرغ در مرورگر.

⌨️ اقدام

مرورگر را رفرش کن.

✅ دستاورد

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

🎯 مسئله

کامیت کردن تغییر نهایی راز سیمرغ.

⌨️ اقدام

git commit -am "feat: تکامل و تکمیل حماسه سیمرغ"

✅ دستاورد

آخرین کامیت داستان ثبت شد.

🎯 مسئله

ثبت تگ نسخه انتشار رسمی 1.0.0 پلتفرم.

⌨️ اقدام

git tag -a v1.0.0 -m "نسخه طلایی ۱.۰.۰ حماسه سیمرغ"

✅ دستاورد

تگ v1.0.0 متولد گردید.

🎯 مسئله

استعلام تگ‌های پروژه.

⌨️ اقدام

git tag

✅ دستاورد

مشاهده v1.0.0 در لیست.

🎯 مسئله

اگر کاتب برچسب نسخه را اشتباهاً روی یک کامیت اشتباه درج کرده باشد، چگونه آن تگ محلی را پاک کند؟

⌨️ اقدام

پرچم -d (Delete) را همراه با نام تگ اجرا کن:

git tag -d v1.0.0

✅ دستاورد

حذف تگ اشتباه از دیتابیس محلی جهت ساخت مجدد روی کامیت درست.

🎯 مسئله

پوش کردن کامیت‌ها به همراه تگ‌ها به گیت‌هاب.

⌨️ اقدام

git push origin main --tags

✅ دستاورد

تمام کامیت‌ها و تگ v1.0.0 روی گیت‌هاب قرار گرفتند.

❓ چالش عیب‌یابی push تگ‌ها

کاتب تگ نسخه v1.0.0 را محلی ساخت و git push origin main را زد. اما تگ در گیت‌هاب ظاهر نشد! چرا تگ منتقل نشد؟

🎓 جمع‌بندی

تبریک! نسخه ۱.۰.۰ منتشر شد. در آخرین درس، پروژه را روی وب‌سایت واقعی زنده (GitHub Pages) منتشر می‌کنی!

پیام حماسی سفر ۳۰ پرنده اکنون آماده است تا بر تمام جهات جهان تابان شود. هدهد فرمود: «با ابزار GitHub Pages، وب‌سایت دفتر سفر تو مستقیماً روی یک دامنه عمومی اینترنت منتشر می‌شود تا هر کسی در جهان بتواند کار تو را تماشا کند!»

🎯 مسئله

ورود به بخش تنظیمات هاستینگ رایگان گیت‌هاب.

⌨️ اقدام

در سایت گیت‌هاب وارد ریپازیتوری شو، روی تب Settings و سپس از منوی چپ روی Pages کلیک کن.

✅ دستاورد

صفحه تنظیمات GitHub Pages باز شد.

🎯 مسئله

تعیین شاخه انتشار وب‌سایت.

⌨️ اقدام

در بخش Build and deployment منوی کشویی Branch را روی main و پوشه را روی / (root) بگذار و دکمه Save را بزن.

✅ دستاورد

فرآیند ساخت و انتشار اتوماتیک آغاز گردید.

🎯 مسئله

دریافت لینک زنده وب‌سایت روی اینترنت.

⌨️ اقدام

چند لحظه صبر کن و صفحه را رفرش کن تا کادر سبز رنگ حاوی لینک عمومی ظاهر شود.

✅ دستاورد

دریافت لینک زنده مانند https://username.github.io/simorgh-journey/.

🎯 مسئله

کلیک روی لینک و باز کردن وب‌سایت زنده روی اینترنت.

⌨️ اقدام

روی دکمه Visit site کلیک کن.

✅ دستاورد

دیدن وب‌سایت واقعی انتشار یافته روی اینترنت!

🎯 مسئله

مرور تمامی بخش‌های صفحه منتشر شده و لذت بردن از دستاورد دوره.

⌨️ اقدام

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

✅ دستاورد

مشاهده نتایج درخشان تمام تلاش‌های دوره گیت.

🎯 مسئله

کپی کردن لینک پورتفولیوی واقعی و قرار دادن آن در رزومه کاری و رزومه پلتفرم موازی.

⌨️ اقدام

لینک سایت زنده را کپی کن.

✅ دستاورد

داشتن یک پروژه واقعی و رزومه‌ای قابل رزومه و ارائه به دیگران.

🎯 مسئله

آموزش آماده‌سازی ساختار انتشار وب‌سایت در پوشه root پروژه جهت شناخته شدن توسط موتور استاتیک GitHub Pages.

⌨️ اقدام

اطمینان از وجود فایل index.html در ریشه اصلی پروژه و اجرای git status جهت تایید آمادگی انتشار.

git status

✅ دستاورد

تایید نهایی سلامت پروژه جهت میزبانی زنده اینترنتی روی دامنه رایگان GitHub Pages.

💡 چیستی و کارکرد میزبانی رایگان (GitHub Pages)

سرویس GitHub Pages به شما اجازه می‌دهد کدهای وب‌سایت فرانت‌اند (HTML, CSS, JS) موجود در ریپازیتوری خود را به صورت کاملاً رایگان و با داشتن دامنه اینترنتی اختصاصی (مانند username.github.io/project) به دنیای وب منتشر کنید.

🚀 ویژگی‌های GitHub Pages:

هر زمان که کدهای جدیدی روی شاخه main push یا merge کنید، گیت‌هاب اتوماتیک وب‌سایت زنده شما را به روزرسانی کرده و بهترین پورتفولیوی کاری برای رزومه شماست.

📜 استعاره داستانی: GitHub Pages تابان شدن نور دفتر سفر سیمرغ بر تمام آفاق و مشرق و مغرب جهان است.

❓ چالش پایانی GitHub Pages

توسعه‌دهنده‌ای وب‌سایت خود را با GitHub Pages منتشر کرده است. اگر تغییر جدیدی روی شاخه main پوش کند، روند به روزرسانی سایت زنده روی اینترنت چگونه خواهد بود؟

👑 تبریک بزرگ! شما فارغ‌التحصیل شدید! 👑

🏆 مدال طلایی «✨ نشان اعظم سیمرغ» آزاد شد 🏆

ای سالک استوار و دبیر گران‌قدر! تو از تمام هفت وادی پرپیچ‌وخم گیت (طلب، عشق، معرفت، استغنا، توحید، حیرت، فقر و فنا) با موفقیت عبور کردی و اکنون به یک مهندس حرفه‌ای و تسلط‌یافته بر Git و GitHub تبدیل شدی. با افتخار نشان طلایی سیمرغ را به تو اهدا می‌کنیم!