مقدمه
در درس قبل با کلیات پلتفرم گیت‌هاب آشنا شدیم. اکنون می‌خواهیم به یکی از مهم‌ترین و تاثیرگذارترین
جنبه‌های آن بپردازیم: نقش گیت‌هاب به عنوان قلب تپنده جنبش نرم‌افزارهای متن‌باز (Open
Source). نرم‌افزار متن‌باز به کدی گفته می‌شود که سورس آن به صورت رایگان و عمومی در دسترس
همگان قرار دارد تا هر کسی بتواند آن را مشاهده، استفاده، اصلاح و توزیع کند.
اگرچه مفهوم متن‌باز بسیار قدیمی‌تر از گیت‌هاب است، اما این پلتفرم با فراهم آوردن ابزارهای مناسب،
انقلابی در نحوه همکاری افراد در پروژه‌های متن‌باز ایجاد کرد و آن را از یک فعالیت محدود به یک
جنبش جهانی و فراگیر تبدیل نمود.
چرا گیت‌هاب خانه پروژه‌های متن‌باز است؟
دلایل متعددی وجود دارد که گیت‌هاب را به انتخاب اول برای میزبانی پروژه‌های متن‌باز تبدیل کرده
است:
دسترسی آسان و شفافیت
گیت‌هاب میزبانی مخازن عمومی را رایگان و بسیار ساده کرد. این امر باعث شد میلیون‌ها پروژه به راحتی
در دسترس عموم قرار گیرند. تمام تاریخچه کد، تمام بحث‌ها پیرامون باگ‌ها (در Issues) و تمام
پیشنهادات برای تغییر کد (در Pull Requests) به صورت شفاف و عمومی ثبت می‌شود. این شفافیت
باعث ایجاد اعتماد و یک فضای سالم برای همکاری می‌شود.
مشارکت آسان با مدل Fork & Pull Request
مهم‌ترین نوآوری گیت‌هاب، ساده‌سازی فرآیند مشارکت بود. در گذشته، مشارکت در یک پروژه متن‌باز
نیازمند طی کردن مراحل پیچیده و کسب مجوزهای لازم بود. اما مدل «Fork and Pull Request» این فرآیند
را به شدت تسهیل کرد. شما برای شروع کار نیازی به هیچ مجوزی ندارید؛ کافیست پروژه را Fork
کنید و کار خود را آغاز نمایید.
جریان کاری مشارکت در پروژه‌های متن‌باز
مشارکت در یک پروژه متن‌باز در گیت‌هاب معمولاً از یک جریان کاری استاندارد پیروی می‌کند. این
فرآیند که در ابتدا ممکن است کمی طولانی به نظر برسد، یک روش بسیار امن و سازمان‌یافته برای
همکاری‌های گسترده و غیرمتمرکز است.
مرحله اول: پیدا کردن یک پروژه و یک Issue
ابتدا باید پروژه‌ای را که به آن علاقه‌مندید پیدا کنید. سپس به بخش Issues آن پروژه بروید.
بسیاری از پروژه‌ها برای راهنمایی تازه‌واردان، برخی از وظایف را با برچسب‌هایی مانند good first
issue یا help wanted مشخص می‌کنند. این‌ها نقاط شروع بسیار خوبی هستند. قبل از شروع
کار، بهتر است در همان Issue یک کامنت بگذارید و اعلام کنید که قصد دارید روی آن کار کنید تا
از انجام کار تکراری توسط دیگران جلوگیری شود.
مرحله دوم: Fork کردن مخزن
شما دسترسی مستقیم برای push کردن تغییرات به مخزن اصلی را ندارید. بنابراین، باید ابتدا
پروژه را Fork کنید. با کلیک روی دکمه Fork، یک کپی کامل از مخزن پروژه تحت
حساب کاربری شما در گیت‌هاب ایجاد می‌شود. این کپی، فضای شخصی شما برای اعمال تغییرات است.
مرحله سوم: Clone کردن Fork شخصی
حالا باید به جای مخزن اصلی، مخزن Fork شده خودتان را روی کامپیوتر محلی خود
clone کنید.
git clone <URL of your fork>
مرحله چهارم: ایجاد یک برنچ جدید
طبق توصیه‌های قبلی، هرگز روی برنچ main کار نکنید. یک برنچ جدید با نامی مرتبط با تغییری که
می‌خواهید ایجاد کنید، بسازید.
git checkout -b fix-login-button
مرحله پنجم تا هفتم: اعمال تغییرات، Push و ارسال Pull Request
حالا می‌توانید تغییرات مورد نظر خود را در کد اعمال کرده و آن‌ها را به صورت محلی کامیت کنید. پس
از اتمام کار، برنچ جدید خود را به مخزن ریموت (یعنی Fork شخصی خودتان) پوش کنید:
git push origin fix-login-button
سپس به صفحه Fork خود در گیت‌هاب بروید. گیت‌هاب به صورت هوشمند تشخیص می‌دهد که شما یک برنچ جدید
را push کرده‌اید و دکمه‌ای برای «Compare & pull request» به شما نمایش می‌دهد. با کلیک روی
آن، به صفحه‌ای هدایت می‌شوید که می‌توانید یک Pull Request (PR) ایجاد کنید. در
این صفحه، یک عنوان و توضیحات کامل برای تغییرات خود بنویسید و توضیح دهید که این PR کدام
Issue را حل می‌کند (مثلاً با نوشتن Closes #123).
مرحله هشتم: بازبینی کد و ادغام
پس از ارسال PR، نگهدارندگان (Maintainers) پروژه کد شما را بازبینی می‌کنند. ممکن
است از شما بخواهند تغییراتی را اعمال کنید. شما می‌توانید تغییرات جدید را روی همان برنچ محلی
کامیت کرده و دوباره push کنید؛ Pull Request شما به صورت خودکار به‌روزرسانی خواهد
شد. پس از اینکه تغییرات شما مورد تایید قرار گرفت، یکی از نگهدارندگان، PR شما را در مخزن
اصلی پروژه ادغام (Merge) خواهد کرد. تبریک، شما اولین مشارکت خود را در یک پروژه متن‌باز
انجام داده‌اید!