Skip to main content

قوانین Git (الزامی)

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

هدف از این قوانین، ایجاد یک فرآیند توسعه کنترل‌شده، قابل رهگیری و استاندارد است تا کیفیت تغییرات، امنیت Branchهای اصلی و شفافیت تاریخچه Git حفظ شود.

تمامی اعضای تیم توسعه موظف به رعایت این قوانین هستند و هرگونه استثنا باید پیش از انجام تغییر، به تأیید مسئول فنی مربوطه برسد.

Branch Protection​

Branchهای محافظت‌شده​

Branchهای اصلی پروژه دارای محدودیت دسترسی هستند و تغییر مستقیم روی آن‌ها مجاز نیست.

Branchهای محافظت‌شده:

  • main
  • develop

قوانین:

  • Commit مستقیم روی main ممنوع است.
  • Commit مستقیم روی develop ممنوع است.
  • Merge مستقیم بدون Merge Request ممنوع است.

تمامی تغییراتی که باید وارد Branchهای اصلی شوند، تنها از طریق Merge Request (MR) انجام می‌شوند.

فرآیند استاندارد:

Working Branch
│
▼
Merge Request
│
▼
Review & Validation
│
▼
Protected Branch

هدف از این محدودیت:

  • اطمینان از انجام Code Review
  • حفظ کیفیت کد
  • جلوگیری از ورود تغییرات بررسی‌نشده
  • ایجاد تاریخچه Git شفاف و قابل رهگیری

Merge Request Policy​

تمامی تغییرات پروژه باید از مسیر Merge Request وارد Branchهای اصلی شوند.

Merge Request صرفاً یک مرحله اداری نیست؛ بلکه فرآیندی برای بررسی تغییرات، دریافت بازخورد فنی، کنترل کیفیت و ثبت دلیل انجام تغییرات است.

قوانین Merge Request​

  • هر Task باید Merge Request مستقل خود را داشته باشد.
  • هر Merge Request باید فقط مربوط به یک JIRA Issue باشد.
  • Scope تغییرات باید محدود به همان Task باشد.

الزامات Merge Request​

هر Merge Request باید شامل موارد زیر باشد:

  • حداقل یک Review تأییدشده
  • اجرای موفق CI (در صورت وجود)
  • توضیح واضح درباره هدف و جزئیات تغییر
  • لینک مرتبط با JIRA Issue
  • Branch مبدأ مطابق استاندارد نام‌گذاری Branchها باشد
  • تغییرات خارج از Scope Task نداشته باشد

Merge Request در شرایط زیر قابل Merge نیست:

  • بدون Review تأییدشده
  • بدون اجرای موفق CI (در صورت فعال بودن)
  • بدون ارتباط با JIRA Issue
  • شامل تغییرات خارج از Scope تعریف‌شده

Hotfix Policy​

Hotfix تنها برای رفع مشکلات بحرانی محیط Production استفاده می‌شود.

استفاده از Hotfix برای توسعه Feature جدید یا تغییرات غیرضروری مجاز نیست.

قوانین Hotfix​

  • Branch مربوط به Hotfix باید از main ایجاد شود.
  • نام Branch باید دقیقاً برابر با JIRA Issue Key مربوط به Hotfix باشد.
  • Scope تغییرات باید فقط محدود به رفع مشکل بحرانی باشد.
  • علت ایجاد Hotfix باید به صورت واضح در Merge Request توضیح داده شود.
  • پس از Merge شدن در main، تغییرات باید در develop نیز Merge شوند.

فرآیند:

main
│
▼
JIRA-ISSUE-KEY
│
▼
main
│
▼
Production
│
▼
develop

Branching Rules​

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

قوانین:

  • نام Branch باید فقط شامل JIRA Issue Key باشد.
  • استفاده از Prefix، Suffix یا توضیحات اضافه در نام Branch ممنوع است.
  • هر Branch کاری فقط برای یک Task ایجاد می‌شود.
  • هر Branch باید تنها یک هدف مشخص داشته باشد.

Rebase Rules​

استفاده از Rebase تنها در شرایط زیر مجاز است:

  • روی Branch شخصی و کاری توسعه‌دهنده

استفاده از Rebase روی Branchهای مشترک ممنوع است:

  • main
  • develop
  • Branchهای تیمی یا Shared

هدف از این محدودیت، جلوگیری از تغییر تاریخچه Branchهایی است که چند نفر روی آن‌ها کار می‌کنند.

Merge Rules​

قوانین Merge:

  • Merge مستقیم بدون Merge Request ممنوع است.
  • استفاده از force push روی Branchهای Shared ممنوع است.
  • تغییر تاریخچه Branchهای اصلی پروژه مجاز نیست.

Conflict Resolution​

مسئولیت حل Conflict بر عهده Owner یا Branch Creator است.

قوانین:

  • توسعه‌دهنده ایجادکننده تغییر باید Conflictها را برطرف کند.
  • در صورت نیاز، باید از Reviewer یا اعضای تیم کمک گرفته شود.
  • پس از حل Conflict، تغییرات باید مجدداً بررسی شوند.
  • Merge بعد از Conflict Resolution بدون بازبینی مجدد ممنوع است.

Breaking Changes​

هرگونه تغییر که باعث شکسته شدن سازگاری نسخه‌های قبلی (Backward Compatibility) شود، باید فرآیند مشخصی داشته باشد.

الزامات:

  • Breaking Change باید پیش از Merge اطلاع‌رسانی شود.
  • نیازمند Approval مربوطه است.
  • باید به صورت واضح در Merge Request مشخص شود.
  • در صورت نیاز باید شامل Migration Plan یا Backward Compatibility Strategy باشد.

Documentation​

تمام تصمیمات مهم فنی و تغییرات غیر بدیهی باید مستندسازی شوند.

محل ثبت تصمیمات:

  • JIRA Issue
  • مستندات پروژه (در صورت وجود)

تغییراتی که فاقد توضیح و مستندات کافی باشند، قابل پذیرش نیستند.

General Rules​

برای حفظ کیفیت و خوانایی تاریخچه Git:

  • هر Merge Request باید کوچک و قابل Review باشد.
  • Commitهای بزرگ و غیرقابل بررسی باید شکسته شوند.
  • تاریخچه Git باید Clean و قابل فهم باقی بماند.
  • تمامی Commitها باید مطابق استاندارد Commit Convention نوشته شوند.
  • تغییرات باید قابل رهگیری از طریق Branch، Commit، Merge Request و JIRA Issue باشند.

جمع‌بندی​

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

رعایت این استانداردها باعث می‌شود:

  • کیفیت تغییرات قبل از ورود به Branchهای اصلی بررسی شود.
  • تاریخچه Git شفاف و قابل رهگیری باقی بماند.
  • ریسک ورود خطا به Production کاهش یابد.
  • هماهنگی بین تیم‌های توسعه، QA و محصول افزایش پیدا کند.

هیچ تغییری نباید بدون مسیر مشخص برای Review، Validation و Traceability وارد Branchهای اصلی پروژه شود.