مشارکت در پروژه‌های متن باز به روش صحیح – بخش دوم

ترتیب کارها را بدهید

در این مرحله، شما با پروژه آشنا شده‌اید و مطمئن هستید که می‌توانید برخی از تغییرات مد نظر را انجام دهید.

موضوع مورد نظر خود را رزرو کنید

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

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

کار را در یک شاخه ذخیره کنید

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

من توصیه می‌کنم یک شاخه را مطابق قرارداد <issue-num> - <issue-name> نام گذاری کنید.

نمونه‌ای از مراجعه به شاخه خاص به صورت زیر خواهد بود:

git checkout -b 345-expose-options-for-gtag

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

آماده برای کامیت

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

پیام پیش فرض git commit را تنظیم کنید

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

یک نکته مفید: هر زمان که شماره را در پیام کامیت خود مانند (<issue-number>#) وارد کنید، شماره مربوطه در ریپازیتوری از راه دور یک اعلان جدول زمانی دریافت می‌کند که به این شکل است:

همه علاقمندان به این موضوع می‌بینند که شما کار روی آن را شروع کرده‌اید.

این می‌تواند به خصوص برای درخواست‌های کشش که در یک بازه زمانی طولانی‌تر قرار دارند، مفید باشد تا به سایر مشارکت کنندگان مسئله‌ای را نشان دهد که شما در حال حاضر روی آن کار می‌کنید و درخواست pull رد نمی‌شود.

نحوه انجام کامیت را در ریپازیتوری انتخابی خود بررسی کنید

این خوب است که بیشتر اوقات با پایبندی به ساختار کامیت کنید، اما من توصیه می‌کنم برای اجرای چگونگی برخورد با پیام‌های کامیت برای اولین بار، پروژه ورود به سیستم git را اجرا کنید.

مطمئن شوید که با دستورالعمل‌های مشارکت ارائه شده مطابقت دارید

قبل از کامیت کردن، دوباره بررسی کنید که تمام الزامات فایل احتمالی CONTRIBUTING.md را برآورده می‌کنید. هر زمان ویژگی جدیدی اضافه کردید، لازم است یک آزمایش واحد مربوطه به پروژه اضافه کنید تا مطمئن شوید تغییرات شما به طور قابل اعتماد کار می‌کنند یا اینکه اسناد را برای توضیح آن ویژگی به روز کنید.

به طور انحصاری روی یک مسئله خاص تمرکز کنید

هیچ کدی را که مربوط به مشکلی که در حال برطرف کردن یا ویژگی در حال اجرا هست، دستکاری نکنید.

گاهی اوقات، بررسی کنندگان درخواست کشش، صریحا به شما می‌گویند تغییراتی را که از روی حسن نیت انجام داده‌اید، برگردانید. دلیل اصلی این است که درخواست pull را به راحتی بخوانید و بررسی کنید و از بحث‌های زمانبر در مورد تغییرات غیرمرتبط در کد جلوگیری کنید.

کامیت‌های اسکواش

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

اگر با کامیت‌های اسکواش آشنا نیستید، این راهنمای مبتدی می‌تواند به شما کمک کند.

آماده برای push

اگر تا این مرحله پیش رفته باشید، عالی است! شما تقریبا آماده افتتاح اولین PR خود هستید. فقط چند قدم مانده است.

ریپازیتوری Fork

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

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

بنابراین اگر تصمیم گرفتید React را  Forkبزنید، چند ثانیه طول می‌کشد و سپس یک نسخه دقیق از ریپازیتوری موجود در https://github.com/<username>/react در اختیار خواهید داشت.

اگرچه مرحله forking را می‌توان زودتر در گردش کار انجام داد، در این مرحله ما قبلا کامیت خود را انجام داده‌ایم، بنابراین مطمئنا می‌دانیم که سهم قابل توجهی در push داریم. اگر قبل از بررسی محلی پروژه و ذخیره کردن یک ریپازیتوری Fork می‌زنید و می‌فهمید که آیا می‌توانید تغییرات ارزشمندی انجام دهید، ممکن است تصمیم بگیرید که دیگر روی آن کار نکنید و بیهوده fork بزنید.

ریموت گیت را تنظیم کنید

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

اگر git remote -v را در محلی که ریپازیتوری را کلون کرده‌اید اجرا کنید، باید شبیه به این باشد: git@github.com:facebook/react.git

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

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

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

# add facebook/react as upstream
git remote add upstream git@github.com:facebook/react.git
# change origin url to be <username>/react
git remote set-url origin git@github.com:<username>/react.git

اگر همه کارها را به درستی انجام داده باشید، خروجی git remote -v باید مبدا و تنظیم upstream را نمایش دهد:

آیا برای شما هم شبیه تصویر بالا است؟ پس تا اینجا خوب پیش رفته‌اید.

Push به مبدا

مراحل باقیمانده بسیار آسان است. ما شاخه‌های خود را با کامیت‌های اسکواشی که به مبدا، یعنی fork ما انجام داده‌ایم، push می‌کنیم.

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

git push origin <branch-name>

عالی است، کارمان تقریبا تمام شده.

آماده برای باز کردن PR

اگر همه کارها را به درستی انجام داده باشید، یک باکس هشدار در محل ریپازیتوری fork به شما نشان داده می‌شود و شما را از push انجام شده مطلع می‌کند.

یک نمونه از درخواست‌های واقعی برای React Carousel.

بعد از اینکه 100٪ کارتان تمام شد، روی دکمه "Compare & pull request" کلیک کنید.

شرح مفیدی برای درخواست push بنویسید

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

این حداقل چیزی است که من آنجا قرار می‌دهم:

Closes #<issue-number>.

<explanation>

گیت هاب کلمه کلیدی "Closes" را تجزیه کرده و با ادغام PR، مسئله را به طور خودکار می‌بندد.

قسمت <توضیح> بسته به مشارکت شما می‌تواند بسیار متفاوت باشد. ممکن است که شما بخواهید مشکلی را که برطرف کرده‌اید توضیح دهید، در مورد مشکلات احتمالی که ممکن است در آینده ظاهر شوند مطلع شوید یا درباره تغییراتی که ممکن است PR انجام دهد، بحث کنید.

به علاوه، ممکن است در برخی ریپازیتوری الگوهای درخواست pull خاصی تنظیم شده باشد. سپس باید کادرهای تأیید را بررسی کنید و مطمئن شوید که مثلا linting بدون خطا انجام می‌شود. شما موارد آزمایشی را برای ویژگی جدید خود اضافه کردید و بسته به ریپازیتوری، هیچ تغییری در قالب‌بندی انجام نمی‌شود.

وقتی به توصیف درخواست کشش خود راضی هستید، تنها کاری که باید انجام دهید این است که بر روی دکمه سبز رنگ "Create pull request" کلیک کنید.

منتظر ماندن برای تایید

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

پایان کار

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

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

البته می‌دانم که اجرای این حجم از توضیحات ممکن است زمان‌بر باشد، اما شما باید تمام مراحل لازم را از صفر تا صد انجام دهید تا بتوانید در این زمینه موفق شوید.

امیدوارم این مقاله برایتان مفید بوده باشد، اگر هرگونه سوال یا پیشنهادی دارید، در بخش زیر با ما در میان بگذارید.

منبع