بازبینی تغییرات

• 1: بازبینی (review) Pull Requestها
• 2: بازبینی برای تأییدکنندگان و بازبین‌ها

1 - بازبینی (review) Pull Requestها

هرکسی می‌تواند یک Pull Request مربوط به مستندات را بازبینی (review) کند. برای دیدن Pull Requestهای باز، به بخش pull requests در مخزن وب‌سایت کوبرنتیز بروید.

بازبینی Pull Requestهای مستندات راه بسیار خوبی برای معرفی خود به جامعه کوبرنتیز است؛ به شما کمک می‌کند با پایگاه کد آشنا شوید و اعتماد سایر مشارکت‌کنندگان را جلب کنید.

پیش از بازبینی، بهتر است:

• راهنمای محتوا و راهنمای سبک را بخوانید تا بتوانید نظرهای آگاهانه بگذارید.
• با نقش‌ها و مسئولیت‌ها‌ در جامعه مستندات کوبرنتیز آشنا شوید.

پیش از شروع

پیش از آن‌که بازبینی را آغاز کنید:

• آیین‌نامه/قواعد رفتاری CNCF را بخوانید و در همه زمان‌ها به آن پایبند باشید.
• مؤدب، ملاحظه‌کار و یاری‌رسان باشید.
• علاوه بر تغییرات، بر جنبه‌های مثبت PRها نیز نظر بگذارید.
• همدل باشید و در نظر داشته باشید بازبینی شما چگونه دریافت می‌شود.
• نیت خوب را فرض کنید و پرسش‌های روشن‌کننده بپرسید.
• مشارکت‌کنندگان باتجربه، با مشارکت‌کنندگان تازه‌ای که کارشان نیاز به تغییرات گسترده دارد جفت شوید.

فرایند بازبینی

به‌طور کلی، Pull Requestها را از نظر محتوا و سبک به زبان انگلیسی بازبینی کنید. شکل ۱ گام‌های فرایند بازبینی را نشان می‌دهد؛ جزئیات هر گام در ادامه آمده است.

شکل ۱. گام‌های فرایند بازبینی.

1. به نشانی https://github.com/kubernetes/website/pulls بروید. فهرستی از همه Pull Requestهای باز برای وب‌سایت و مستندات کوبرنتیز را می‌بینید.

2. Pull Requestهای باز را با استفاده از یک یا همه برچسب‌های زیر فیلتر کنید:

   • cncf-cla: yes (پیشنهاد می‌شود): PRهایی که نویسنده آن‌ها CLA را امضا نکرده است نمی‌توانند ادغام شوند. برای اطلاعات بیش‌تر بخش، CLA امضا را ببینید.
   • language/en (پیشنهاد می‌شود): فقط PRهای زبان انگلیسی را فیلتر می‌کند.
   • size/<size>: PRها را بر اساس اندازه فیلتر می‌کند. اگر تازه‌کار هستید، با PRهای کوچک‌تر شروع کنید.

   همچنین مطمئن شوید PR با برچسب work in progress علامت‌گذاری نشده باشد؛ چنین PRهایی هنوز آماده بازبینی نیستند.

3. پس از انتخاب یک PR برای بازبینی، تغییرات را با انجام کارهای زیر درک کنید:

   • توضیحات PR را بخوانید تا تغییرات انجام‌شده را بفهمید و هر Issue پیوند‌شده را بررسی کنید.
   • نظرهای سایر بازبین‌ها را بخوانید.
   • روی تب Files changed کلیک کنید تا فایل (پرونده)‌ها و خطوط تغییر‌یافته را ببینید.
   • پیش‌نمایش تغییرات را در ساخت پیش‌نمایش Netlify مشاهده کنید. برای این کار، در تب Conversation به بخش بررسی ساخت Netlify که در پایین صفحه قرار دارد بروید.
     (این تصویر مربوط به نسخه دسکتاپ GitHub است؛ اگر در تبلت یا تلفن همراه بازبینی می‌کنید، رابط کاربری GitHub کمی متفاوت است):

     

     برای باز کردن پیش‌نمایش، روی پیوند Details در خط deploy/netlify در فهرست بررسی‌ها کلیک کنید.

4. به تب Files changed بروید تا بازبینی را آغاز کنید.

   1. روی نماد + کنار خطی که می‌خواهید نظر بدهید کلیک کنید.
   2. نظر خود را درباره آن خط بنویسید و روی Add single comment (اگر تنها یک نظر دارید) یا Start a review (اگر چند نظر دارید) کلیک کنید.
   3. پس از پایان، در بالای صفحه روی Review changes کلیک کنید. اینجا می‌توانید خلاصه‌ای از بازبینی خود (و چند نظر مثبت برای مشارکت‌کننده!) بنویسید. لطفاً همیشه از دکمه "Comment" استفاده کنید.

   • هنگام پایان بازبینی، از کلیک روی دکمه "Request changes" پرهیز کنید.
     اگر می‌خواهید پیش از اعمال تغییرات بیشتر مانع ادغام PR شوید، می‌توانید کامنت /hold بگذارید. دلیل hold را ذکر کنید و در صورت تمایل شرایط برداشتن آن را مشخص کنید.

   • هنگام پایان بازبینی، از کلیک روی دکمه "Approve" پرهیز کنید. بیشتر مواقع گذاشتن کامنت /approve توصیه می‌شود.

چک‌لیست بازبینی

هنگام بازبینی، از موارد زیر به‌عنوان نقطه شروع استفاده کنید.

زبان و دستور زبان

• ‌آیا خطاهای آشکاری در زبان یا دستور زبان وجود دارد؟ آیا راه بهتری برای بیان یک جمله هست؟
  • روی زبان و دستور زبان بخش‌هایی از صفحه که نویسنده تغییر داده تمرکز کنید. مگر این‌که نویسنده آشکارا قصد به‌روزرسانی کل صفحه را داشته باشد، او الزام ندارد همه اشکالات صفحه را برطرف کند.
  • وقتی یک PR صفحه‌ای موجود را به‌روزرسانی می‌کند، روی بخش‌های تغییر یافته صفحه بازبینی کنید. آن محتوا باید از نظر فنی و ویرایشی درست باشد. اگر خطاهایی پیدا کردید که مستقیماً به هدف نویسنده مرتبط نیست، آن را در یک Issue جداگانه مطرح کنید (البته ابتدا مطمئن شوید Issue مشابهی وجود ندارد).
  • مراقب Pull Requestهایی باشید که محتوا را جابه‌جا می‌کنند. اگر نویسنده صفحه‌ای را تغییر نام می‌دهد یا دو صفحه را ادغام می‌کند، ما (SIG Docs کوبرنتیز) معمولاً از او نمی‌خواهیم همه ایرادهای املایی یا دستور زبانی موجود در محتوای جابه‌جا شده را برطرف کند.
• آیا واژه‌های پیچیده یا کهنه‌ای هست که بتوان آن‌ها را با واژه‌ای ساده‌تر جایگزین کرد؟
• آیا واژه، اصطلاح یا عبارتی هست که بتوان آن را با جایگزینی غیرتبعیض‌آمیز عوض کرد؟
• آیا انتخاب واژه و حروف بزرگ/کوچک کردن آن با راهنمای سبک هماهنگ است؟
• آیا جمله‌های طولانی وجود دارد که می‌تواند کوتاه‌تر یا ساده‌تر شود؟
• آیا پاراگراف‌های طولانی وجود دارد که شاید به‌صورت فهرست یا جدول بهتر باشند؟

محتوا

• آیا محتوای مشابهی در جای دیگری از سایت کوبرنتیز وجود دارد؟
• آیا محتوا بیش از حد به مستندات خارج از وب‌سایت، مستندات متعلق به یک فروشنده ی خاص یا مستندات غیرمتن‌باز پیوند می‌دهد؟

مستندات

چند بررسی که باید در نظر گرفت:

• آیا این PR عنوان، slug/alias یا پیوند لنگری (anchor link) صفحه‌ای را تغییر داده یا حذف کرده است؟ اگر بله، آیا در نتیجه این PR پیوند‌های شکسته‌ای ایجاد شده است؟ آیا گزینه دیگری مثل تغییر عنوان صفحه بدون تغییر slug وجود دارد؟

• آیا PR صفحه‌ای جدید اضافه می‌کند؟ اگر بله:

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

• آیا تغییرات در پیش‌نمایش Netlify نمایش داده می‌شوند؟ درباره فهرست‌ها، بلاک‌های کد، جدول‌ها، نکته‌ها و تصاویر دقیق باشید.

وب‌نوشت (blog)

بازخورد زودهنگام درباره پست‌های وب‌نوشت (blog) از طریق Google Doc یا HackMD استقبال می‌شود. لطفاً درخواست خود را از کانال Slack #sig-docs-blog زودتر ارسال کنید.

پیش از بازبینی PRهای وب‌نوشت (blog)، با راهنمای وب‌نوشت (blog) و ارسال پست وب‌نوشت (blog) و مطالعات موردی آشنا باشید.

همچنین درباره مقالات evergreen و نحوه تصمیم‌گیری درباره evergreen بودن مقاله اطلاعات داشته باشید.

مقالات وب‌نوشت (blog) ممکن است شامل نقل‌قول مستقیم و گفتار غیرمستقیم باشند. برای متنی که به فردی نسبت داده شده یا بخشی از گفت‌وگویی واقعی است، پیشنهاد بازنویسی ندهید—حتی اگر دستور زبان گوینده اصلی درست نباشد. در این موارد همچنین سعی کنید علامات نگارشی پیشنهادی نویسنده را حفظ کنید مگر اینکه واضحاً اشتباه باشد.

به‌عنوان پروژه، فقط زمانی مقالات وب‌نوشت (blog) را با برچسب نگه‌داری (evergreen: true در front matter) علامت می‌کنیم که پروژه Kubernetes متعهد باشد آن‌ها را به‌طور نامحدود نگه‌داری کند. برخی مقالات قطعاً ارزش این کار را دارند و ما همیشه اطلاعیه‌های انتشار را evergreen علامت می‌کنیم. اگر درباره نحوه بازبینی این مورد مطمئن نیستید، با سایر مشارکت‌کنندگان مشورت کنید.

راهنمای محتوا بدون قید و شرط بر مقالات وب‌نوشت (blog) و PRهایی که آن‌ها را اضافه می‌کنند اعمال می‌شود. به یاد داشته باشید برخی محدودیت‌ها فقط به مستندات مربوط‌اند و برای مقالات وب‌نوشت (blog) صدق نمی‌کنند.

بررسی کنید که منبع Markdown از نوع مناسب محتوای صفحه و / یا layout مناسب استفاده می‌کند.

سایر

مراقب ویرایش‌های جزئی (Trivial Edits) باشید؛ اگر تغییری را ویرایش جزئی تشخیص می‌دهید، این سیاست را یادآور شوید (اگر واقعاً بهبود است، قبول تغییر اشکالی ندارد).

نویسندگانی را که در حال انجام اصلاحات مربوط به فاصله‌گذاری (whitespace) هستند تشویق کنید که این کار را در اولین commit PR خود انجام دهند و سپس تغییرات دیگر را روی آن اضافه کنند. این کار هم ادغام (merge) و هم بازبینی‌ها را ساده‌تر می‌کند. به‌ویژه مراقب تغییرات جزئی باشید که همراه با مقدار زیادی اصلاح فاصله‌گذاری در یک commit واحد انجام شده‌اند (و اگر چنین موردی دیدید، نویسنده را تشویق کنید تا آن را اصلاح کند).

به‌عنوان بازبین، اگر مسائل کوچکی در PR یافتید که برای معنا حیاتی نیستند، مثل غلط‌های املایی یا فاصله نادرست، نظر خود را با پیشوند nit: بنویسید. این به نویسنده نشان می‌دهد این بخش از بازخورد شما غیر بحرانی است.

اگر در حال بررسی تأیید یک Pull Request هستید و تمام بازخوردهای باقی‌مانده با nit علامت‌گذاری شده‌اند، می‌توانید PR را ادغام کنید. در این حالت، توصیه می‌شود برای موارد nit باقی‌مانده یک issue جدید باز کنید. همچنین در نظر بگیرید که آیا می‌توانید آن issue جدید را به‌عنوان Good First Issue علامت‌گذاری کنید یا خیر؛ اگر امکان‌پذیر باشد، این ها منابع خوبی (برای مشارکت‌کنندگان تازه‌وارد) خواهند بود.

2 - بازبینی برای تأییدکنندگان و بازبین‌ها

بازبین‌ها (Reviewers) و تأییدکنندگان (Approvers) در SIG Docs هنگام بازبینی یک تغییر چند کار اضافه نیز انجام می‌دهند.

هر هفته یکی از تأییدکنندگان مستندات (docs approver) داوطلب می‌شود تا Pull Requestها را تریاژ (triage) و بازبینی کند. این فرد در آن هفته "PR Wrangler" است. برای اطلاعات بیشتر، به زمان‌بندی PR Wrangler مراجعه کنید. برای تبدیل شدن به PR Wrangler، در نشست هفتگی SIG Docs شرکت کنید و داوطلب شوید. حتی اگر در برنامهٔ همین هفته نام شما نیست، هنوز هم می‌توانید Pull Requestهایی (PRها) را که در حال حاضر تحت بازبینی فعال نیستند، بررسی کنید.

علاوه بر چرخشی بودن، یک بات بازبین‌ها و تأییدکنندگان PR را بر اساس مالکیت فایل (پرونده)‌های تحت تأثیر تعیین می‌کند.

بازبینی یک PR

مستندات کوبرنتیز از فرآیند بازبینی کد کوبرنتیز پیروی می‌کند.

هر آنچه در بازبینی یک Pull Request آمده است صدق می‌کند، اما بازبین‌ها و تأییدکنندگان باید کارهای زیر را نیز انجام دهند:

• استفاده از دستور Prow /assign برای اختصاص دادن یک بازبین مشخص به یک Pull Request در صورت نیاز. این کار به‌ویژه زمانی اهمیت بیشتری دارد که نیاز به درخواست بازبینی فنی از مشارکت‌کنندگان کد باشد.

  Note:

  به فیلد reviewers در front-matter بالای فایل (پرونده) Markdown نگاه کنید تا ببینید چه کسی می‌تواند بازبینی فنی انجام دهد.

• اطمینان از اینکه PR مطابق با راهنمای محتوا و راهنمای سبک است؛ اگر این‌طور نیست، نویسنده را به بخش مربوطه در راهنما(ها) ارجاع دهید.

• استفاده از گزینه Request Changes در GitHub در صورت لزوم برای پیشنهاد تغییر به نویسنده PR.

• تغییر وضعیت بازبینی خود در GitHub با استفاده از دستورات Prow /approve یا /lgtm
  اگر پیشنهادهای شما اعمال شده‌اند.

commit در PR شخص دیگر

گذاشتن نظر در PR مفید است، اما گاهی ممکن است لازم باشد در Pull Request شخص دیگری commit کنید.

هرگز کار شخص دیگری را «به‌دست نگیرید» مگر اینکه خود او صراحتاً درخواست کرده باشد یا قصد داشته باشید یک PR قدیمی و رهاشده را احیا کنید. گرچه این کار ممکن است در کوتاه‌مدت سریع‌تر باشد، اما فرصت مشارکت را از آن فرد می‌گیرد.

روش کار بستگی دارد به اینکه آیا نیاز دارید فایلی (پرونده‌ای) را ویرایش کنید که در دامنهٔ PR است یا فایلی (پرونده‌ای) را که هنوز در آن PR تغییری نکرده است.

شما نمی‌توانید در PR شخص دیگر commit کنید اگر یکی از شرایط زیر برقرار باشد:

• اگر نویسنده PR شاخه (branch) خود را مستقیماً به مخزن https://github.com/kubernetes/website/ پوش کرده باشد. تنها بازبینی‌کننده‌ای با دسترسی push می‌تواند در PR کاربر دیگر commit کند.

  Note:

  نویسنده را تشویق کنید دفعه بعد شاخه خود را در fork شخصی بسازد و سپس PR باز کند.

• نویسنده PR به‌صراحت ویرایش توسط تأییدکنندگان را غیرفعال کرده باشد.

دستورات Prow برای بازبینی

Prow سیستم CI/CD مبتنی بر کوبرنتیز است که روی Pull Requestها اجرا می‌شود.
Prow امکان استفاده از دستورات شبیه به چت‌بات را فراهم می‌کند تا کارهای GitHub مانند افزودن یا حذف برچسب‌ها، بستن Issueها و تعیین تاییدکنندگان را مدیریت کند.
دستورات Prow به‌صورت کامنت در GitHub و با فرمت /<command-name> نوشته می‌شوند.

رایج‌ترین دستورات Prow برای بازبین‌ها و تأییدکنندگان عبارتند از:

برای دیدن لیست کامل دستورات قابل استفاده در PR، به Prow مرجع دستورات مراجعه کنید.

دسته‌بندی و اولویت‌بندی Issueها

به‌طور کلی، SIG Docs از فرآیند تریاژ Issueها در کوبرنتیز پیروی می‌کند و از همان برچسب‌ها استفاده می‌کند.

این فیلتر در GitHub، فهرستی از issueها را پیدا می‌کند که ممکن است به تریاژ نیاز داشته باشند.

Triage یک Issue

1. اعتبارسنجی Issue

   • مطمئن شوید که Issue مربوط به مستندات وب‌سایت است. برخی Issueها با پاسخ سریع یا ارجاع بسته می‌شوند.
     (به بخش درخواست‌های پشتیبانی یا گزارش باگ کد مراجعه کنید.)
   • بررسی کنید که Issue ارزش پیگیری دارد یا نه.
   • اگر Issue جزئیات کافی ندارد یا قالب به‌درستی پر نشده، برچسب triage/needs-information اضافه کنید.
   • اگر Issue هم lifecycle/stale و هم triage/needs-information دارد، آن را ببندید.

2. افزودن برچسب اولویت (برای جزئیات کامل به دستورالعمل‌های تریاژ Issue‌ها مراجعه کنید)

در صورت صلاحدید، مالکیت یک Issue را بر عهده بگیرید و برای آن PR ارسال کنید (به‌ویژه اگر سریع انجام می‌شود یا مرتبط با کاری است که همین حالا انجام می‌دهید).

اگر درباره تریاژ یک Issue پرسشی داشتید، در کانال #sig-docs در Slack یا لیست ایمیل kubernetes-sig-docs بپرسید.

افزودن و حذف برچسب های Issue

برای افزودن برچسب، یکی از قالب‌های زیر را در کامنت بگذارید:

• /<label-to-add> (مثال: /good-first-issue)
• /<label-category> <label-to-add> (مثال: /triage needs-information یا /language ja)

برای حذف برچسب:

• /remove-<label-to-remove> (مثال: /remove-help)
• /remove-<label-category> <label-to-remove> (مثال: /remove-triage needs-information)

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

لیست همه برچسب‌ها در بخش برچسب‌های مخزن وب‌سایت موجود است. همه برچسب‌ها توسط SIG Docs استفاده نمی‌شوند.

برچسب‌های چرخه عمر Issue

Issueها معمولاً به‌سرعت باز و بسته می‌شوند. بااین‌حال، گاهی یک Issue پس از باز شدن غیرفعال می‌شود و گاهی لازم است بیش از ۹۰ روز باز بماند.

مدیریت انواع خاص Issueها

SIG Docs به‌اندازه‌ای با انواع زیر از Issue مواجه می‌شود که لازم است شیوه رسیدگی به آن‌ها مستند شود.

Issueهای تکراری

اگر یک مشکل واحد بیش از یک Issue باز دارد، آن‌ها را در یک Issue ادغام کنید. تصمیم بگیرید کدام Issue باز بماند (یا یک Issue جدید باز کنید)، سپس تمام اطلاعات مرتبط را منتقل کرده و Issueهای مرتبط را پیوند کنید. در نهایت، به همه Issueهای دیگر که همان مشکل را توصیف می‌کنند برچسب triage/duplicate بزنید و آن‌ها را ببندید. داشتن یک Issue منفرد، سردرگمی را کاهش می‌دهد و از دوباره‌کاری جلوگیری می‌کند.

Issueهای مربوط به پیوند‌های خراب

اگر Issue پیوند مرده در مستندات API یا kubectl است، تا زمانی که مشکل کاملاً درک شود به آن برچسب /priority critical-urgent بدهید.
به تمام Issueهای پیوند مرده دیگر برچسب /priority important-longterm بدهید، چون باید به‌صورت دستی رفع شوند.

Issueهای وب‌نوشت (blog)

انتظار می‌رود مطالب وب‌نوشت (blog) کوبرنتیز با گذر زمان قدیمی شوند؛ بنابراین فقط مطالب کمتر از یک‌سال را نگه‌داری می‌کنیم.
اگر Issue مربوط به مطلبی قدیمی‌تر از یک سال است، معمولاً باید Issue را بدون رفع ببندید.

می‌توانید هنگام بستن PR، پیوندی به به‌روزرسانی و نگه‌داری مقاله بفرستید.

در صورت وجود توجیه مناسب، ایجاد استثنا اشکالی ندارد.

درخواست های پشتیبانی یا گزارش باگ کد

برخی از Issueهای مربوط به مستندات در واقع به کد اصلی مربوط می‌شوند یا درخواست کمک هستند، برای مثال زمانی که یک آموزش (tutorial) درست کار نمی‌کند. برای Issueهایی که به مستندات مربوط نیستند، آن‌ها را با برچسب kind/support ببندید و در یک کامنت، درخواست‌کننده را به کانال‌های پشتیبانی دیگر (مانند Slack یا Stack Overflow) راهنمایی کنید. اگر Issue مربوط به باگ در یک قابلیت باشد، درخواست‌کننده را به مخزن مرتبط هدایت کنید (مخزن kubernetes/kubernetes نقطهٔ شروع مناسبی است).

نمونه پاسخ به درخواست پشتیبانی:

This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.

You can also open issues for Kubernetes functionality in
https://github.com/kubernetes/kubernetes.

If this is a documentation issue, please re-open this issue.

نمونه پاسخ به گزارش باگ کد:

This sounds more like an issue with the code than an issue with
the documentation. Please open an issue at
https://github.com/kubernetes/kubernetes/issues.

If this is a documentation issue, please re-open this issue.

squash کردن (Squashing)

به‌عنوان یک تأییدکننده، هنگام بازبینی Pull Requestها (PRها) ممکن است در شرایط مختلف یکی از کارهای زیر را انجام دهید:

• به مشارکت‌کننده توصیه کنید commit‌هایش را squash کند.
• commit‌ها را به‌جای مشارکت‌کننده squash کنید.
• به مشارکت‌کننده توصیه کنید هنوز squash نکند.
• مانع از squash شدن شوید.

توصیه به مشارکت‌کنندگان برای squash: یک مشارکت‌کننده تازه‌وارد ممکن است نداند که باید commit‌هایش را در PR squash کند. در این صورت، او را راهنمایی کنید، پیوندهای مفید در اختیارش بگذارید و در صورت نیاز پیشنهاد کمک بدهید. چند پیوند مفید:

• باز کردن Pull Request و squash commit‌ها برای مشارکت‌کنندگان مستندات
• گردش کار GitHub (شامل نمودارها) برای توسعه‌دهندگان

squash commit برای مشارکت‌کنندگان: اگر مشارکت‌کننده ممکن است در squash کردن مشکل داشته باشد یا فشار زمانی برای ادغام PR وجود دارد، می‌توانید squash را برای او انجام دهید:

• مخزن kubernetes/website برای اجازه squash هنگام ادغام PR پیکربندی شده است. کافی است دکمه Squash commits را بزنید.

• در یک PR، اگر مشارکت‌کننده اجازهٔ مدیریت PR را به نگه‌دارندگان (maintainers) بدهد، می‌توانید commit‌های او را squash کنید و fork او را با نتیجهٔ نهایی به‌روزرسانی نمایید. پیش از انجام squash، به او توصیه کنید آخرین تغییرات خود را ذخیره کرده و به PR پوش کند. پس از squash نیز به او بگویید commit squash‌ شده را به کلون محلی خود pull کند.

• همچنین می‌توانید با استفاده از یک برچسب (label) کاری کنید که GitHub commit‌ها را squash کند، به‌طوری که Tide / GitHub این کار را انجام دهند؛ یا هنگام ادغام PR روی دکمهٔ Squash commits کلیک کنید.

توصیه برای پرهیز از squash

• اگر یک commit تغییرات خراب‌کننده یا نادرستی انجام داده باشد و commit آخر برای بازگرداندن (revert) آن خطا باشد، در این حالت commit‌ها را squash نکنید. حتی اگر در تب "Files changed" در PR در GitHub و در پیش‌نمایش Netlify همه‌چیز درست به‌نظر برسد، ادغام چنین PRی می‌تواند برای دیگر مشارکت‌کنندگان باعث ایجاد conflict در rebase یا merge شود. در چنین شرایطی، متناسب با صلاح‌دید خود مداخله کنید تا از ایجاد مشکل برای دیگر مشارکت‌کنندگان جلوگیری شود.

هرگز squash نکنید

اگر در حال راه‌اندازی یک بومی‌سازی (localization) یا انتشار مستندات برای یک نسخهٔ جدید هستید، در این حالت شاخه‌ای را ادغام می‌کنید که از fork یک کاربر نیست؛ در چنین شرایطی هرگز commit‌ها را squash نکنید. عدم squash در اینجا ضروری است زیرا باید تاریخچهٔ کامل commit‌ها برای آن فایل (پرونده)‌ها حفظ شود.