مقدمه
گیت‌هاب فقط محلی برای ذخیره کد نیست؛ این پلتفرم یک مجموعه ابزار یکپارچه و قدرتمند برای مدیریت
کامل چرخه حیات توسعه نرم‌افزار ارائه می‌دهد. بسیاری از تیم‌ها از ابزارهای جداگانه‌ای مانند Jira
یا Trello برای مدیریت پروژه استفاده می‌کنند، اما گیت‌هاب با ارائه ابزارهای داخلی، این امکان را
فراهم می‌کند که مدیریت وظایف و کدنویسی در یک مکان واحد و در کنار هم انجام شوند. این یکپارچگی،
شفافیت و قابلیت ردیابی را به شدت افزایش می‌دهد.
در این درس، با دو جزء اصلی مدیریت پروژه در گیت‌هاب آشنا می‌شویم: GitHub Issues
برای ردیابی وظایف و GitHub Projects برای بصری‌سازی جریان کاری.
هسته اصلی ردیابی وظایف: GitHub Issues
Issue در گیت‌هاب یک واحد کاری است که می‌تواند هر چیزی باشد: یک گزارش باگ، یک درخواست برای
قابلیت جدید، یک سوال فنی، یا یک وظیفه برای نوشتن مستندات. هر Issue مانند یک پرونده عمل
می‌کند که تمام بحث‌ها و فعالیت‌های مربوط به آن وظیفه در آن ثبت می‌شود.
آناتومی یک Issue
هر Issue از اجزای مختلفی تشکیل شده که به سازماندهی بهتر کارها کمک می‌کند:
- عنوان و توضیحات: قلب هر Issue. عنوان باید خلاصه و گویا باشد و بخش توضیحات باید
جزئیات کامل وظیفه را شرح دهد (مثلاً برای یک باگ، مراحل بازتولید آن ذکر شود).
- برچسب‌ها (Labels): ابزاری قدرتمند برای دسته‌بندی Issueها. شما می‌توانید
برچسب‌هایی مانند bug، enhancement، documentation، priority:high
یا good first issue بسازید تا فیلتر کردن و پیدا کردن وظایف مرتبط آسان شود.
- مسئولین (Assignees): شما می‌توانید یک یا چند نفر از اعضای تیم را به عنوان مسئول انجام
آن Issue تعیین کنید.
- مایلستون‌ها (Milestones): برای گروه‌بندی Issueهایی که به یک هدف مشترک تعلق
دارند (مانند یک اسپرینت یا نسخه جدید نرم‌افزار) استفاده می‌شود. مایلستون‌ها می‌توانند تاریخ
سررسید داشته باشند و درصد پیشرفت آن‌ها به صورت خودکار نمایش داده می‌شود.
بصری‌سازی جریان کاری با GitHub Projects
GitHub Projects در واقع تخته‌های کانبان (Kanban Boards) هستند که مستقیماً در گیت‌هاب
تعبیه شده‌اند. این ابزار به تیم‌ها کمک می‌کند تا وظایف خود را سازماندهی و اولویت‌بندی کرده و یک
نمای کلی و بصری از وضعیت پروژه داشته باشند.
یک تخته پروژه معمولاً شامل ستون‌هایی است که مراحل مختلف جریان کاری را نشان می‌دهند، مانند:
- To Do (برای انجام): لیستی از کارهایی که باید انجام شوند.
- In Progress (در حال انجام): وظایفی که یکی از اعضای تیم در حال کار بر روی آن‌هاست.
- In Review (در حال بازبینی): کدهایی که کارشان تمام شده و برای بازبینی در قالب یک
Pull Request ارسال شده‌اند.
- Done (انجام‌شده): وظایفی که با موفقیت تکمیل و ادغام شده‌اند.
هر Issue به عنوان یک کارت روی این تخته نمایش داده می‌شود و با پیشرفت کار، بین ستون‌ها
جابجا می‌شود. یکی از قابلیت‌های کلیدی Projects، امکان اتوماسیون است.
برای مثال، شما می‌توانید قانونی تعریف کنید که «هرگاه یک Pull Request برای یک Issue
باز شد، کارت آن را به صورت خودکار به ستون In Review منتقل کن».
جریان کاری یکپارچه: از Issue تا کد
قدرت واقعی این ابزارها زمانی مشخص می‌شود که به صورت یکپارچه استفاده شوند. یک جریان کاری
استاندارد به این صورت است:
- یک وظیفه جدید در قالب یک Issue تعریف می‌شود.
- توسعه‌دهنده یک برنچ جدید برای کار روی آن Issue ایجاد می‌کند (بهتر
است شماره Issue در نام برنچ ذکر شود، مثلاً feature/123-new-login).
- توسعه‌دهنده کد را نوشته و در پیام کامیت‌های خود به شماره Issue ارجاع می‌دهد (مثلاً
`git commit -m "Refactor login logic, see #123"`).
- یک Pull Request باز می‌شود. در توضیحات PR، از کلمات کلیدی مانند
Closes #123 یا Fixes #123 استفاده می‌شود.
- کد بازبینی شده و در نهایت Merge می‌شود.
با ادغام شدن Pull Request، گیت‌هاب به صورت هوشمند کلمه کلیدی Closes #123 را تشخیص
داده و به طور خودکار آن Issue را می‌بندد. این فرآیند یک تاریخچه کاملاً قابل
ردیابی ایجاد می‌کند که در آن هر خط کد به یک وظیفه مشخص متصل است.