مشارکت در کدایگنایتر

  • دوشنبه 22 مرداد 1397 ساعت 11:55
  • 3.1.9
  • در حال تکمیل
  • فعال

 گدایگنایتر یک پروژه مبتنی بر کامیونیتی (جامعه‌ای از کاربران) است و مشارکت‌های اعضا در توسعه کد و داکیومنت را می‌پذیرد. این مشارکت‌ها می‌تواند به شکل ایشو (issue) یا پول ریکوئست (Pull Requests) در ریپازیتوری کدایگنایتر در گیت‌هاب صورت پذیرد.

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

  • هیچ ایشوی بازی در این رابطه وجود نداشته باشد.
  • مشکل مورد نظر، هنوز رفع نشده باشد (برنچ develop را چک کنید، یا ایشوهای بسته شده را ببینید.)
  • آیا کاملا مشخص است که خودتان آن را حل کرده‌اید؟

گزارش دادن مشکلات به وسیله ایشوها کاری مفید است، اما ارسال پول ریکوئست شیوه به مراتب بهتری است، برای اینکار ریپازیتوری اصلی را فورک (Fork) کرده و پس از اعمال تغییرات، نسخه کپی خود را کامیت کنید. برای اینکار باید از گیت استفاده کنید که یک سیستم کنترل ورژن (VCS) است.

پشتیبانی

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

اگر مطمئن نیستید که مشکل شما به خاطر عدم استفاده درست است یا یک باگ در کدایگنایتر یافته‌اید، لطفا ابتدا آن را در انجمن کدایگنایتر مطرح کنید.

امنیت

آیا یک مشکل امنیتی در کدایگنایتر یافته‌اید؟

لطفا آن را به صورت عمومی افشا نکنید، بلکه به security@codeigniter.com ایمیل بفرستید، یا آن را در پیج کدایگنایتر در HackerOne مطرح کنید.

اگر آسیب‌پذیری مهمی را یافته‌اید، با خوشحالی از شما در لاگ تغییرات <../changelog> قدردانی خواهیم کرد.

نکاتی برای ریپورت یک ایشوی خوب

به جای یک عنوان مبهم (برای مثال your code broke)، از عنوانی توصیفی (برای مثال parser library chokes on commas) استفاده کنید.

در هر ایشو تنها به یک مشکل اشاره کنید.

ورژن کدایگنایتر (برای مثال 3.0-develop) را مشخص کنید و اگر نام کامپوننت (برای مثال parser library) را می‌دانید، آن را نیز را ذکر کنید.

توضیح دهید که انتظار داشته‌اید چه اتفاقی بیفتد و در عمل چه اتفاقی افتاده است. در صورت وجود، پیام‌های خطا و استک‌تریس (stacktrace) را نیز درج کنید.

اگر به توضیحات کمک می‌کند، بخش‌هایی کوتاه از کدهای خود را نیز درج کنید. برای درجِ بخش‌های طولانی‌تری از کدها یا اسکرین‌شات‌ها، از pastebin یا dropbox استفاده کنید - آن‌ها را در ایشوی خود قرار ندهید. این به این معنی است که سررسیدی مناسب برای آن‌ها تعیین کنید تا زمانی که ایشو، حل یا بسته شود.

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

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

دستورالعمل‌ها

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

اصطلاحات فنی

کد پایه یا کدبیس (Codebase)، به مجموعه‌ای از سورس کدها می‌گویند که برای ساخت یک سیستم نرم‌افزاری خاص، اپلیکیشن یا کامپوننت نرم‌افزاری استفاده می‌شوند.

سبک کدنویسی PHP

تمام کدها باید با راهنمای کدنویسی مطابقت داشته باشند، که در آن رعایت استایل Allman برای تورفتگی‌ها، آندراسکور و عملگرهای خوانا، ضروری است. این کار باعث می‌شود تا تمام کدها دارای فرمتی مشابه کدهای موجود باشند و این به این معنی است که تا حد ممکن خوانا خواهند بود.

مستندسازی

اگر چیزی را تغییر دادید که مستلزم تغییری در مستندات است، باید آن را نیز اضافه کنید. کلاس‌ها، متدها و پارامترهای جدید، تغییر مقادیر پیش‌فرض و غیره، مواردی هستند که مستلزم اعمال تغییرات در مستندات هستند. با هر تغییر، change-log نیز باید آپدیت شود. همچنین بلاک‌های PHPDoc باید حفظ شوند.

سازگاری

کدایگنایتر توصیه می‌کند که از PHP 5.6 یا جدیدتر استفاده شود، اما با PHP 5.3.7 باید سازگار باشد، بنابراین تمام کدهای ارائه شده باید این الزام را برآورده سازند. اگر از فانکشن‌ها یا فیچرهای PHP 5.4 (یا بالاتر) استفاده کردید، باید یک راه جایگزین برای استفاده در PHP 5.3.7 وجود داشته باشد.

برنچینگ

کدایگنایتر از مدل برنچینگ Git-Flow استفاده می‌کند که نیاز به ارسال تمامی پول ریکوئست‌ها به برنچ develop دارد. این برنچ جایی است که نسخه برنامه‌ریزی شده بعدی در آن توسعه خواهد یافت. برنچ master همیشه حاوی آخرین ورژنِ استیبل (پایدار) و مرتب و واضح است، یک هات‌فیکس (به عنوان مثال: یک پَچ امنیتی اضطراری) می‌تواند به master اعمال شود تا یک نسخه جدید ایجاد شود بدون نگرانی درباره توقف سایر فیچرها. به همین دلیل، تمام کامیت‌ها باید به develop ارسال شود و هر ارسالی به master، به صورت خودکار بسته خواهد شد. اگر چندین تغییر برای ارسال دارید، لطفا هر کدام را در برنچ خودش در فورک‌تان قرار دهید.

اصطلاحات فنی

هات‌فیکس یا اصطلاحیه (hotfix)، یک آپدیت نرم‌افزاری است که در نظر گرفته شده تا یک باگ یا مشکل امنیتی در یک برنامه را برطرف کند. برخلاف آپدیت‌های ورژن‌های متداول، هات‌فیکس‌ها به سرعت توسعه می‌یابند و به محض امکان ریلیس می‌شوند تا اثرات مشکل نرم‌افزاری را محدود سازند.

نکته: از آنجایی که هات‌فیکس‌ها برای برطرف کردن یک مشکل خاص در نظر گرفته می‌شوند، معمولا اندازه کوچکی دارند. به همین دلیل، یک هات‌فیکس می‌تواند یک پَچ نیز نامیده شود زیرا یک باگ یا حفره امنیتی را پَچ (اصلاح) می‌کند.

هر چیزی در زمان خودش، سعی نکنید همه کارها را به یکباره انجام دهید: هر پول ریکوئست تنها باید دارای یک تغییر باشد. این به معنی یک کامیت نیست، بلکه منظور یک تغییر است، گرچه ممکن است به چندین کامیت نیاز باشد. دلیل این امر این است که اگر X و Y را تغییر دهید، اما هر دو را با یک پول ریکوئست ارسال کنید اما تنها تغییر X را بخواهیم و با تغییر Y موافق نباشیم که بیانگر این است که ریکوئست را مِرج کنیم. با استفاده از مدل برنچینگ Git-Flow، می‌توانید برنچ‌های جدیدی برای هر دوی این فیچرها بسازید و دو ریکوئست بفرستید.

ساین کردن

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

git commit --signoff

یا کافی است:

git commit -s

این دستور، کامیت‌های شما را با اطلاعات تنظیم شده در کانفیگ گیت‌تان، ساین می‌کند، برای مثال:

Signed-off-by: John Q Public <john.public@example.com>

اگر از Tower استفاده می‌کنید، در پنجره commit، یک چک‌باکس با لیبل Sign-Off وجود دارد. یا حتی می‌توانید از -s (اسم مستعار --signoff) به عنوان فلگ (flag) دستور git commit استفاده کنید بنابراین مجبور نیستید درباره آن فکر کنید.

با ساین کردن کارهای خود به این شیوه، گواهی مبدأ توسعه‌دهنده را تایید می‌کنید. ورژن فعلی این گواهی، در گواهی مبدأ توسعه دهنده 1.1 در زیر همین لینک بزودی در دسترس خواهد بود.

سایر پست‌های داکیومنت

بخش ها

سایر پست های داکیومنت

تگ ها