فرادرسقالبهای گیت هاب برای درخواست‌های Pull یکپارچه و هوشمندانه – راهنمای کاربردی
در این مقاله قصد داریم یک روش بهتر، آسان‌تر و کارآمدتر برای حفظ یکپارچگی در میان درخواست‌های pull گیت‌هاب و حتی سفارشی‌سازی کامل آنها در یک تیم توسعه معرفی کنیم. امکان این کار به کمک قالب های گیت هاب فراهم شده است.
مشکلات رایج
اگر تاکنون به عنوان یک توسعه‌دهنده نرم‌افزار با گیت‌هاب کارکرده باشید، چه این کار را به صورت انفرادی انجام داده باشید و چه بخشی از یک تیم بوده باشید، احتمالاً با مشکلاتی که در ادامه معرفی خواهیم کرد آشنا هستید.
درج پیام‌های کامیت خیلی کوتاه
نخستین مشکل رایج پیام کامیت بی‌معنی است. این پیام‌ها عموماً چندین بار ارسال می‌شوند، چون ما توسعه‌دهندگان تنبلی هستیم و عادت داریم تغییرات مختلف را با پیام‌های یکسانی به گیت‌هاب پوش کنیم و هیچ توجه نداریم که آن تغییرات هیچ ارتباطی با پیام مربوطه ندارند.
نکته: اگر می‌خواهید برخی پیام‌های کامیت جالب و سرگرم‌کننده را بخوانید، سری به این وب‌سایت (+) بزنید. با رفرش کردن صفحه پیام‌های کامیت عجیب‌وغریبی را مشاهده خواهید کرد.
درخواست‌های Pull کاملاً معماگونه
احتمالاً یک درخواست pull مانند درخواست زیر را در یک ریپو دیده‌اید (و یا ارسال کرده‌اید). تلاش نکنید انکار کنید! نام و جزییات جهت حفظ حریم خصوصی پنهان شده‌اند:
تصویر فوق یک درخواست pull واقعی روی گیت‌هاب است و پیام‌های کامیت فراوانی دارد که معنی بسیار کمی دارند و برای کسی که به آنها نگاه می‌کند جزییات چندانی از آنچه در حال اتفاق افتادن است ارائه نمی‌کنند.
در این مرحله، ممکن است با خود فکر کنید، این کار در واقع شبیه همان کاری است که خودتان قبلاً دیده‌اید (انجام داده‌اید) و مشکل چندانی ایجاد نمی‌کند.
اگر یک توسعه‌دهنده منفرد هستید که روی پروژه شخصی خود کار می‌کنید، همواره از همه چیز در کدبیس اطلاع دارید و شاید حق با شما باشد. اما اگر در حال کار با تیمی متشکل از 10 یا 20 توسعه‌دهنده دیگر هستید و یک اپلیکیشن می‌سازید که از سوی صدها یا هزاران نفر استفاده می‌شود و توسعه‌دهندگان دیگر باید تغییراتی که شما ایجاد کرده‌اید را ببینند و تشخیص دهند که کد منطقی است یا نه و در ادامه هیچ مشکلی در شاخه master کد ایجاد نمی‌کند، در این صورت با یک مشکل بسیار بزرگ مواجه هستیم.
راه‌حل‌ها
برای حل این مشکل‌ها چند راه‌حل مختلف وجود دارند که ممکن است گذشته تجربه کرده باشید.
گزینه 1: فرایند کاملاً دستی
یک مجموعه نسبی از الزامات داریم که باید به هر درخواست pull جدید اضافه کنیم. این موارد چیزهایی مانند این هستند:
- لینک‌هایی به روند قابلیتی که مشغول کار روی آن هستیم روی backlog.
- لینک‌هایی به Jenkiks خودکار که شاخه ما بر مبنای آن ساخته شده و درون QA توزیع یافته است.
- لینک‌هایی به شاخه قابلیت برای تست کردن.
- گزارش پوشش کد
- لینک‌های به PR-های مرتبط در ریپوهای دیگر و غیره.
این راه‌حل به درستی کار می‌کند، مگر این که افراد اضافه کردن یکی یا چند مورد از این لینک‌ها را فراموش کنند (یا به آن اهمیت ندهند) و یک سیستم صورت‌بندی برای اعضای جدید که به تیم ملحق می‌شوند نداشته باشیم تا بدانند قالب PR-هایشان باید چگونه باشد.
گزینه 2: قالبی که باید کپی شده و هر بار در PR چسبانده شود
تلاش دوم ما کمی غیر دستی‌تر است. در این روش از یک قالب درخواست pull استفاده می‌شود که تیم می‌تواند در یک فایل txt. در اسلک نگهداری کند و آن را در یکی از کانال‌های تیم توسعه پین کند. ظاهر آن می‌تواند به صورت زیر باشد:
Story
Jira, Pivotal Tracker, (link to where the story you worked on lives)
PR Branch
URL to the automated branch build for feature testing
Code Coverage
URL to the automated code coverage report run during the automated build process
e2e
URL to the automated end to end tests run against the feature branch
UX Approved
yes / no
Newman
yes / no
Related PR's
TBD
اما در این حالت هم اعضای تیم باید بروند و دنبال قالب بگردند، قالب‌بندی نشانه‌گذاری آن را کپی کنند و آن را درون همه درخواست‌های pull وارد کرده و محتوای آن را نیز پر کنند.
این گزینه بهتری محسوب می‌شود، زیرا دست‌کم قالب تضمین می‌کند که احتمال فراموش کردن موارد مختلف کمتر است، اما همچنان مستعد خطا است. در اغلب موارد افراد تیم به سراغ PR-های قدیمی می‌روند، آن را باز می‌کنند و محتوای آن را کپی کرده و در PR جدید می‌چسبانند. البته این کار اشکالی ندارد، اما گاهی افراد فراموش می‌کنند که لینک استوری را به‌روز کنند یا لینک سربه‌سر تست را درج نمی‌کنند و مشکل پیش می‌آید.
این بهترین راه‌حلی بود که اعضای تیم می‌توانستند داشته باشند تا این که برخی توسعه‌دهندگان تازه‌کار به تیم ما اضافه شدند. زمانی که راه‌حل بهینه خود یعنی قالب PR را که استفاده می‌کردیم به اعضای جدید تیم نشان دادیم، آنها پرسیدند که چرا از قالب‌های گیت‌هاب استفاده نمی‌کنیم؟ پاسخ ما این بود که: «چون هیچ یک از ما تاکنون چیزی در مورد آن نشنیده‌ایم!» در نهایت بدین ترتیب با این مفهوم به شدت جالب و البته آسان آشنا شدیم.
گزینه 3: قالب‌های گیت هاب؛ روش خودکار برای انجام درخواست Pull
این گزینه راه‌حل بهتری محسوب می‌شود و در واقع راه‌حلی است که هرکس باید استفاده کند. قالب‌های گیت‌هاب ابداع بسیار جالبی از سوی گیت‌هاب برای درخواست‌های pull و همچنین issue-ها محسوب می‌شوند. از آنجا که PR-ها دغدغه هر تیم توسعه‌ای هستند، به مستندات گیت‌هاب مراجعه کردیم تا در مورد آن بیشتر بدانیم:
زمانی که یک قالب درخواست pull به ریپازیتوری خود اضافه کنید، مشارکت‌کنندگان در پروژه به صورت خودکار محتوای قالب را در بدنه درخواست pull خود مشاهده خواهند کرد.
این همان چیزی است که هر تیم توسعه‌ای نیاز دارد. این روش تضمین می‌کند که همه درخواست‌های pull یک شکل هستند و لازم نیست اعضای تیم در مورد آن نگرانی داشته باشند. راه‌اندازی آن نیز بسیار آسان است.
راه‌اندازی قالب‌های گیت هاب در یک پروژه
با این که راه‌اندازی یک قالب PR بسیار سرراست است، اما برای سهولت هر چه بیشتر در ادامه مراحل آن را توضیح داده‌ایم.
گام 1: افزودن یک پوشه /github. به ریشه پروژه
مستندات این بخش بیان می‌کنند که می‌توان یک قالب PR را در خود ریشه دایرکتوری پروژه یا در پوشه‌ای به نام /docs یا /github. اضافه کرد. از آنجا که ما می‌خواهیم پوشه PR را در اغلب موارد که مشغول توسعه هستیم نادیده بگیریم. تصمیم گرفتیم پوشه قالب را درون پوشه /github. بسازیم:
گام 2: افزودن فایل نشانه‌گذاری pull_request_template.md درون پوشه
برای این که گیت‌هاب به صورت خودکار قالب‌بندی را از فایل نشانه‌گذاری برای قالب‌های PR بردارد، باید نام فایل را pull_request_template.md بگذارید. در ادامه نمونه‌ای از قالبی که تیم ما استفاده می‌کند را می‌بینید:
Tracker ID: #ADD LINK TO PIVOTAL STORY
Unit tests completed?: (Y/N)
PR Branch #ADD LINK TO PR BRANCH
Code Coverage & Build Info #ADD LINK TO JENKINS CONSOLE
E2E Approved #ADD LINK TO PASSING E2E TESTS
Windows Testing #HAS WINDOWS BEEN TESTED?
Related PR #ADD ANY RELATED PULL REQUESTS
UX Approved #ADD UX APPROVAL IF NEEDED
گام 3: افزودن این فایل‌ها به شاخه master و آماده‌سازی همه درخواست‌های PR
در ادامه تصویری از یک ریپازیتوری را می‌بینید که قالب درخواست PR به آن اضافه شده و یک درخواست pull نیز به عنوان نمونه ایجاد شده است:
افزودن یک قالب PR استاندارد به هر ریپازیتوری دقیقاً به همین سادگی است.
سخن پایانی
زمانی که با تیمی از توسعه‌دهندگان سر و کار داریم که روی محصولی حساس مشغول کار هستند، درخواست‌های pull یک ضرورت حیاتی محسوب می‌شوند، اما به کمک امکان pull_request_templates در گیت‌هاب این مشکل می‌تواند به آسانی مرتفع شود.
مزیت‌های قالب‌های صورت‌بندی شده PR زیاد هستند، اما برخی از آنها که می‌توان اشاره کرد میزان انعطاف‌پذیری آنها است. مهم نیست که تیم شما چه چیزی را مورد بررسی و پذیرش قرار می‌دهد، یک درخواست Pull را می‌توان به سادگی در هر ریپازیتوری جای داده و پیاده‌سازی کرد. این همان نوع از سهولت کار توسعه‌دهنده‌ها است که برای صورت‌بندی موارد ضروری مانند PR-ها به آن نیاز داریم.
اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:
- مجموعه آموزش‌های برنامهنویسی
- آموزش گیت (Git) برای مدیریت نسخه توزیع شده
- مجموعه آموزش‌های دروس علوم و مهندسی کامپیوتر
- ساخت مخزن گیت هاب — از صفر تا صد
- 1۰ ویژگی کاربردی گیت هاب (GitHub) که باید آنها را بدانید — راهنمای کاربردی
==
