مقدمه
در طول این دوره، با قطعات مختلف پازل گیت و گیت‌هاب آشنا شدیم: از کامیت‌ها و برنچ‌ها گرفته تا
Issues و Pull Requests. اکنون زمان آن است که تمام این قطعات را کنار هم بگذاریم و
تصویر بزرگتر را ببینیم: جریان کاری گیت‌هاب (GitHub Workflow).
این جریان کاری، یک استراتژی و مجموعه‌ای از بهترین روش‌هاست که توسط میلیون‌ها توسعه‌دهنده و تیم
در سراسر جهان برای ساخت نرم‌افزار به صورت مشترک استفاده می‌شود. این درس یک جمع‌بندی کامل از این
فرآیند یکپارچه، از لحظه تولد یک ایده تا انتشار آن برای کاربران، ارائه می‌دهد.
جریان کاری کامل: از ایده تا استقرار
بیایید داستان توسعه یک قابلیت جدید را از ابتدا تا انتها دنبال کنیم تا ببینیم چگونه تمام ابزارها
در کنار هم قرار می‌گیرند.
مرحله ۱: همه چیز با یک Issue شروع می‌شود
هیچ کدی نباید بدون دلیل نوشته شود. هر کار جدیدی، چه یک قابلیت تازه و چه رفع یک باگ، باید ابتدا
به عنوان یک Issue در گیت‌هاب ثبت شود. این کار به تیم اجازه می‌دهد تا در مورد
نیازمندی‌ها بحث کرده، آن را اولویت‌بندی کنند و یک نفر را به عنوان مسئول به آن تخصیص دهند.
مرحله ۲: یک برنچ توصیفی بسازید
توسعه‌دهنده مسئول، کار خود را با ساختن یک برنچ جدید از آخرین نسخه برنچ main آغاز می‌کند.
نام برنچ باید گویا بوده و بهتر است شماره Issue مربوطه را نیز در خود داشته باشد تا ارتباط
آن‌ها واضح باشد.
git checkout -b feature/42-user-avatar-upload
مرحله ۳: کدنویسی و کامیت‌های اتمی
توسعه‌دهنده در محیط ایزوله برنچ خود، شروع به کدنویسی می‌کند. او تغییرات خود را در قالب کامیت‌های
کوچک و اتمی با پیام‌های واضح ثبت می‌کند و به طور منظم برنچ خود را به سرور ریموت push
می‌کند تا کارش پشتیبان‌گیری شده و برای دیگران قابل مشاهده باشد.
مرحله ۴: برای گفتگو، یک Pull Request باز کنید
به محض اینکه بخشی از کار آماده نمایش یا نیازمند بازخورد باشد، توسعه‌دهنده یک Pull
Request از برنچ خود به برنچ main باز می‌کند. در توضیحات PR، هدف
تغییرات را شرح داده و با استفاده از کلمه کلیدی مانند Closes #42، آن را به
Issue اصلی متصل می‌کند.
مرحله ۵: با بازبینی کد، همکاری کنید
اکنون PR به مرکز همکاری تیم تبدیل می‌شود. سایر اعضا کد را در تب «Files Changed» بازبینی
کرده، کامنت می‌گذارند و پیشنهاداتی برای بهبود ارائه می‌دهند. همزمان، سیستم‌های خودکار (GitHub
Actions) تست‌ها را اجرا می‌کنند. توسعه‌دهنده به بازخوردها با push کردن کامیت‌های
جدید پاسخ می‌دهد تا زمانی که PR تایید نهایی را دریافت کند.
مرحله ۶ و ۷: ادغام و استقرار
پس از تایید و سبز شدن تمام تست‌ها، یک مدیر پروژه PR را در برنچ main
ادغام یا Merge می‌کند. برنچ کاری نیز پس از ادغام حذف می‌شود تا مخزن تمیز بماند.
ادغام شدن در main به این معنی است که کد برای انتشار آماده است. در بسیاری از تیم‌های مدرن،
این عمل به صورت خودکار یک فرآیند استقرار (Deployment) را از طریق GitHub Actions
فعال می‌کند که نسخه جدید نرم‌افزار را برای کاربران منتشر می‌کند.
خلاصه بصری جریان کاری
این فرآیند را می‌توان به صورت زیر خلاصه کرد:
Issue → Branch → Commits → Pull Request → Code Review → Merge → Deploy
این چرخه، یک فرآیند ساختاریافته، شفاف و ایمن را برای توسعه نرم‌افزار در تیم‌ها فراهم می‌کند که
ریسک را به حداقل رسانده و همکاری را به حداکثر می‌رساند.