آموزش بیش از ۵۰۰ سوال و جواب مصاحبه Git و GitHub سال ۲۰۲۶ - آخرین آپدیت

پوشش دقیق حوزه‌های آزمون

این بانک تست تمرینی به گونه‌ای ساختاریافته است که توزیع فنی و سناریوهای حل مسئله را دقیقاً مطابق با مصاحبه‌های سخت‌گیرانه مهندسی و DevOps بازسازی کند.

• مبانی Git (۲۰٪): مقداردهی اولیه مخزن (git init)، مکانیزم‌های Staging (git add)، کامیت‌های اتمیک (git commit)، بررسی تاریخچه کامیت‌ها (git log) و جداسازی شاخه‌های محلی (git branch).

• جریان‌های کاری GitHub (۲۰٪): همگام‌سازی از راه دور (git push, git pull)، استراتژی‌های ادغام شاخه‌ها (git merge, git rebase) و مدیریت تغییرات ذخیره نشده (git stash).

• همکاری و شاخه‌بندی (۱۵٪): الگوهای همکاری در پروژه‌های متن‌باز و سازمانی (git fork)، اتصال از راه دور (git clone, git remote, git fetch) و چرخه عمر Pull Requestها.

• حل تضادها و عیب‌یابی (۱۰٪): حل تضادهای پیچیده Merge، اصلاح ایمن تاریخچه (git reset, git revert)، جداسازی کامیت‌های تکه تکه (git cherry-pick) و بازیابی از فاجعه از طریق reflog (git reflog).

• ویژگی‌ها و ابزارهای GitHub (۱۰٪): مکانیزم‌های ردیابی پروژه (GitHub issues, GitHub projects)، مستندات تیمی (GitHub wiki)، استقرار استاتیک (GitHub pages) و اتوماسیون داخلی (GitHub actions).

• طراحی سیستم و معماری (۱۰٪): مدیریت استراتژی‌های کنترل نسخه در معماری‌های متنوع، از جمله الگوهای میکروسرویس، ساختارهای Monolithic، سیستم‌های سرویس‌گرا و جریان‌های داده Event-driven.

• ساختارهای داده و الگوریتم‌ها (۵٪): درک مدل‌سازی داخلی داده‌ها در Git، از جمله اینکه چگونه گراف‌ها، درخت‌ها، آرایه‌ها، لیست‌های پیوندی، پشته‌ها و صف‌ها تاریخچه کامیت‌ها و ذخیره‌سازی اشیاء را تعیین می‌کنند.

• DevOps و یکپارچه‌سازی مداوم (۱۰٪): جریان‌های کاری یکپارچه‌سازی که مخازن Git را به موتورهای CI/CD مانند Jenkins، Travis CI، Circle CI، کانتینرهای Docker و کلاسترهای Kubernetes متصل می‌کند.

درباره دوره

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

تک تک سوالات این بانک از ابتدا نوشته شده‌اند تا گلوگاه‌های واقعی مهندسی را منعکس کنند؛ از وضعیت‌های detached HEAD و Rebasingهای پیچیده تا پیکربندی جریان‌های کاری قدرتمند GitHub Actions در محیط‌های مختلف. من تحلیل‌های جامع برای هر گزینه ارائه می‌دهم و مکانیزم‌های زیربنایی ساختارهای داده Git و نحوه تعامل دستورات محلی با خط لوله‌های اصلی DevOps را بررسی می‌کنم. اگر برای مراحل فنی تایید سیستم آماده می‌شوید، یا می‌خواهید پیش از ارزیابی ارتقاء به سطح Senior جریان‌های استقرار را مرور کنید، این مجموعه آمادگی حرفه‌ای مورد نیاز شما را فراهم می‌کند.

نمونه‌ای از سوالات تمرینی

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

سوال ۱: دستکاری پیشرفته تاریخچه و بازیابی کامیت‌ها از طریق Reflog

یک توسعه‌دهنده از دستور git reset --hard HEAD~3 برای پاک کردن کامیت‌های اخیر استفاده می‌کند، اما متوجه می‌شود که تغییرات معماری حیاتی و ادغام‌نشده در یکی از آن کامیت‌ها از دست رفته است. هش کامیت دیگر در خروجی استاندارد git log قابل مشاهده نیست. کدام توالی دستورات امن‌ترین مسیر برای بازیابی کار از دست رفته را فراهم می‌کند؟

• الف) اجرای git revert HEAD~3 برای بازتولید خودکار اشیاء کامیت گم شده در ایندکس فعلی.

• ب) اجرای git reflog برای شناسایی هش SHA-1 دقیق کامیت قبل از ریست، و سپس استفاده از git cherry-pick [hash] یا git reset --hard [hash] برای بازیابی آن.

• ج) استفاده از git fsck --lost-found برای مقداردهی اولیه مجدد گره کامیت ریشه به شاخه ردیابی origin main اولیه.

• د) اجرای git checkout --force همراه با شناسه‌ ردیابی راه دور برای دریافت تغییرات ادغام نشده از سرور Upstream.

• ه) اجرای git stash pop برای اجبار موتور ذخیره‌سازی داخلی به بازسازی فایل‌های شیء گم شده از حافظه کاری موقت.

• و) اجرای git branch --set-upstream-to با اشاره مستقیم به آخرین مکان شناخته شده head برای اجبار به تطبیق تاریخی.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا درست است: Git یک لاگ مرجع محلی به نام reflog نگهداری می‌کند که هر به‌روزرسانی انجام شده در نوک شاخه‌ها و سایر مراجع را ردیابی می‌کند. حتی اگر کامیت‌ها از گراف استاندارد جدا شده و در git log مخفی باشند، تا زمان اجرای Garbage Collection در پایگاه داده اشیاء Git باقی می‌مانند. شناسایی SHA-1 هدف از طریق git reflog و اجرای git reset --hard [hash] اشاره‌گر شاخه را دقیقاً به آن حالت بازمی‌گرداند.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: git revert یک کامیت جدید ایجاد می‌کند که تغییرات یک کامیت موجود و قابل مشاهده را خنثی می‌کند؛ این دستور نمی‌تواند کامیت‌های جدا شده از درخت تاریخچه فعلی را هدف قرار دهد.

  • گزینه ج نادرست است: اگرچه git fsck می‌تواند اشیاء معلق را شناسایی کند، اما فایل‌ها را بدون متن و زمینه در پوشه lost-found می‌ریزد که بسیار tediousتر و ناامن‌تر از استفاده از reflog است.

  • گزینه د نادرست است: Checkout با force تغییرات محلی ذخیره نشده را پاک می‌کند و با ایندکس فعلی مطابقت می‌دهد؛ این کار حالت‌های کامیت محلی قدیمی‌تر را ردیابی یا بازیابی نمی‌کند.

  • گزینه ه نادرست است: عملیات Stash تغییراتی را مدیریت می‌کند که صریحاً توسط کاربر ذخیره شده‌اند؛ این عملیات تاریخچه کامیت شده‌ای را که از طریق hard reset پاک شده ردیابی نمی‌کند.

  • گزینه و نادرست است: تغییر پیکربندی ردیابی upstream روابط راه دور را تغییر می‌دهد اما اشاره‌گرهای کامیت حذف شده محلی را تعمیر یا باز نمی‌گرداند.

سوال ۲: همگام‌سازی معماری از طریق Git Rebase در مقابل Git Merge

در طول مرحله ادغام یک ویژگی در یک معماری میکروسرویس، لیدر تیم دستور می‌دهد که به جای اجرای git merge feature از شاخه main، از دستور git rebase main روی شاخه ویژگی محلی استفاده شود. این دستور چه تأثیری بر تاریخچه نهایی کامیت‌های پروژه دارد؟

• الف) تمام کامیت‌های ویژگی را در یک شیء blob فشرده ترکیب کرده و تمام پیام‌های هر مشارکت‌کننده را کاملاً حذف می‌کند.

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

• ج) تاریخچه کامیت را بازنویسی می‌کند؛ به این صورت که کامیت‌های شاخه ویژگی محلی را برداشته و مستقیماً روی نوک شاخه هدف (main) اعمال می‌کند و در نتیجه یک تاریخچه کاملاً خطی ایجاد می‌شود.

• د) بررسی‌های اعتبارسنجی محلی را کاملاً دور می‌زند و تغییرات شاخه محلی را بدون Staging مستقیماً به سرور origin راه دور ارسال می‌کند.

• ه) شاخه محلی را به یک بلوک معماری مخزن Monolithic تبدیل کرده و تمام ردیابی‌های شاخه زیرپوشه را متوقف می‌کند.

• و) فایل ایندکس مخزن را قفل می‌کند تا از انجام Pull Requestهای همزمان توسط سایر توسعه‌دهندگان تا پایان rebase جلوگیری کند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

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

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: Rebase کامیت‌های متمایز و پیام‌های آن‌ها را حفظ می‌کند، مگر اینکه دستور صریح squash در طول یک rebase تعاملی اضافه شود.

  • گزینه ب نادرست است: حفظ ساختار تاریخچه متقاطع چند شاخه ویژگی مستقیم git merge است، نه rebase.

  • گزینه د نادرست است: Rebase کاملاً یک مکانیزم تغییر تاریخچه محلی است و تا زمانی که دستور push صادر نشود، به سرور راه دور دست نمی‌زند.

  • گزینه ه نادرست است: دستورات Git گراف‌های کامیت را تغییر می‌دهند، نه نوع معماری برنامه یا محدودیت‌های ساختاری دایرکتوری را.

  • گزینه و نادرست است: این عملیات فقط بر ایندکس فضای کاری محلی تأثیر می‌گذارد و هرگز قفل دسترسی راه دور روی سایر همکاران ایجاد نمی‌کند.

سوال ۳: تشخیص خطاهای یکپارچه‌سازی مداوم در خط لوله‌های GitHub Actions

یک مهندس DevOps یک فایل جریان کاری GitHub Actions (.github/workflows/ci.yml) را پیکربندی می‌کند تا هر زمان که توسعه‌دهنده‌ای یک Pull Request باز می‌کند، یک کانتینر Docker بسازد. جریان کاری هنگام اجرا به طور مداوم با خطای "Resource Not Found" یا خطای اعتبارسنجی مجوز (Permission) بلافاصله پس از تلاش برای به‌روزرسانی برچسب‌های وضعیت در رابط Pull Request شکست می‌خورد. علت ریشه‌ای چیست؟

• الف) فایل جریان کاری به صورت فیزیکی در دایرکتوری اشتباه مخزن قرار گرفته است، مثلاً در پوشه .github/projects/.

• ب) پیکربندی از سینتکس سیستمی اشتباهی استفاده می‌کند و سعی دارد یک بلوک پیکربندی آرایه را در یک نقشه کلید-مقدار استاندارد تجزیه کند.

• ج) جریان کاری فاقد بلوک صریح permissions: است که قابلیت write: pull-requests را به GITHUB_TOKEN تولید شده به صورت خودکار اعطا کند.

• د) کانتینرهای Docker اساساً با GitHub runners ناسازگار هستند مگر اینکه یک سرور Jenkins میزبانی شده توسط شخص ثالث مراحل اجرا را مدیریت کند.

• ه) مخزن هدف تمام عملیات‌های git fetch ورودی را غیرفعال کرده است و مانع از مشاهده متادیتای Pull Request توسط Runner می‌شود.

• و) محیط Runner به طور پیش‌فرض از یک نسخه قدیمی سیستم‌عامل استفاده می‌کند که نمی‌تواند رویدادهای Webhook را تجزیه کند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• چرا درست است: به طور پیش‌فرض، توکن امنیتی تولید شده خودکار (GITHUB_TOKEN) که به Runnerها ارائه می‌شود، تحت مجوزهای محدود read-only عمل می‌کند تا از مخازن در برابر اجرای کدهای مخرب در Pull Requestهای ارسالی از Forkها محافظت کند. اگر یک Job نیاز به تغییر دارایی‌های مخزن، ارسال کامنت یا به‌روزرسانی متادیتایی مانند برچسب‌های وضعیت PR داشته باشد، باید صریحاً مجوزهای write را در ساختار YAML با استفاده از کلمه کلیدی permissions: تعریف کنید.

• چرا گزینه‌های دیگر نادرست هستند:

  • گزینه الف نادرست است: اگر فایل در پوشه اشتباه بود، GitHub Actions کاملاً آن را نادیده می‌گرفت و هرگز اجرا نمی‌شد یا وضعیتی نشان نمی‌داد.

  • گزینه ب نادرست است: خطاهای سینتکس پایه YAML مانع از تجزیه کامل فایل می‌شود و باعث خطاهای Linting می‌شود، نه بلوک‌های مجوز در زمان اجرا.

  • گزینه د نادرست است: Runnerهای میزبانی شده توسط GitHub دارای پشتیبانی داخلی از Docker هستند و اجازه اجرای مراحل ساخت کانتینر را می‌دهند.

  • گزینه ه نادرست است: Runnerهای GitHub کدها را به صورت محلی از طریق APIهای داخلی امن دریافت می‌کنند؛ غیرفعال کردن دستورات fetch خارجی تأثیری بر Action ندارد.

  • گزینه و نادرست است: ماشین‌های مجازی Runner به صورت پویا توسط GitHub مدیریت و به‌روزرسانی می‌شوند؛ بنابراین مسائل مجوز توسط سیاست‌های احراز هویت تعیین می‌شوند، نه سن سیستم‌عامل میزبان.

چه انتظاراتی داشته باشید

• به تست‌های سوالات مصاحبه خوش آمدید تا شما را برای آزمون تمرینی سوالات مصاحبه Git و GitHub آماده کنیم.

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

• این یک بانک سوالات عظیم و اورجینال است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح دقیق است.

• با اپلیکیشن Udemy سازگار با موبایل است.

امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.