Ruleset مجموعهٔ قوانین روی شاخه است — مثلاً push مستقیم به main ممنوع، CI باید سبز باشد، Merge فقط بعد از Approve. از Branch Protection قدیمی کامل‌تر است.
🎯 اهداف یادگیری
- Ruleset را به‌جای یک تیک ساده طراحی کنی
- required checks، review و linear history را قفل کنی
- Environments را برای production بفهمی
- CODEOWNERS را به سیاست وصل کنی
🧱 چرا Rulesets؟
| Branch protection | Rulesets | |
|---|---|---|
| تعداد سیاست | یکی per branch | چند لایه قابل‌ترکیب |
| هدف | نام شاخه | الگو (release/**) + tagging |
| Bypass | ضعیف | نقش / تیم / App مشخص |
| سازمان | محدود | ارث‌بری Enterprise → Org → Repo |
| ارزیابی | — | تاریخچهٔ ارزیابی و بینش |
حداقل سیاست main در ۲۰۲۶:
- Restrict deletions
- Block force pushes
- Require a pull request (۱–۲ Approve)
- Require status checks to pass (CI)
- Require conversation resolution
- Require signed commits (اگر تیم آماده است)
- Dismiss stale reviews on new push
- Require review from Code Owners
👥 CODEOWNERS
* @rezaian-dev /src/build.py @rezaian-dev /docs/ @docs-team *.yml @platform-team
آخرین قانونِ مطابق برنده است. بدون Ruleset «code owners»، این فایل فقط مستندات است.
🌍 Environments
برای Actions:
staging— بدون دروازهproduction— required reviewers + wait timer + restricted secrets
حتی اگر شاخه آزاد باشد، deploy به production بدون Approve انسانی نمی‌رود. از ۲۰۲۵ Immutable Releases هم دارایی و تگ عرضه را قفل می‌کند.
🖥️ اثر روی VS Code
اگر مستقیم روی main کامیت کنی:
- محلی:
git.branchProtectionهشدار می‌دهد - push: سرور رد می‌کند با پیام Ruleset
پیام خطا را بخوان؛ معمولاً لینک به کدام rule است.
v* را قفل کن تا کسی تگ نسخه را جابه‌جا نکند. همراه Immutable Releases، عرضه قابل‌اثبات می‌شود.
Mid — linear history یعنی چه؟ فقط fast-forward؛ merge commit روی main ممنوع. با squash یا rebase merge جور است.
Senior — bypass چه کسی باید داشته باشد؟ فقط bot حادثه و چند admin. اگر همه bypass دارند، سیاست تئاتر است.
✅ چک‌لیست فهم
- force push روی main بسته است
- CI required است نه تزئینی
- production Environment Approve دارد
- CODEOWNERS زنده است
فصل بعد: GitHub Actions از صفر تا OIDC.