دستورالعملهای گیت — سازمانی (Enterprise)
فهرست بخشها
استانداردهای کامیت
بخش توضیحات کاملهدف
پیامهای کامیت تاریخچهٔ قابل خواندن توسط انسانِ مخزن هستند. استاندارد قوی قابل ردیابی بودن را افزایش میدهد، ساخت خودکار چَنجلاگ را ممکن میسازد و فرآیند بررسی را ساده میکند.
قوانین اصلی (فارسی)
- از قالب Conventional Commits استفاده کنید:
type(scope?): subject - Typeها:
feat,fix,chore,docs,refactor,perf,test,build,ci,revert - Subject: زمان حال، بدون نقطهٔ پایانی، حداکثر ۷۲ کاراکتر پیشنهاد میشود
- بدنه: در ۷۲ کاراکتر شکست بزنید، دلیل را توضیح دهید نه فقط چه چیزی تغییر کرده
- فوتر: ارجاع به issueها و تغییرات breaking:
BREAKING CHANGE: ...
مثالها
feat(auth): افزودن بررسی انقضای JWT fix(api): هندل کردن null برای user در endpoint /me docs(readme): افزودن نکات ارتقا به نسخهٔ v2
چرا اجرا؟
برای خودکارسازی انتشار، بهتر شدن بررسیها و آسانتر شدن ردگیری و حسابرسی تاریخچه.
استانداردهای شاخهبندی
بخش توضیحات کاملنمای کلی
انواع شاخه و قوانین نامگذاری: main، develop، feature/، hotfix/، release/ را تعریف کنید.
نامگذاری
main— آمادهٔ تولیدdevelop— شاخهٔ یکپارچهسازی (اختیاری)feature/ISSUE-123-add-loginhotfix/v1.2.1release/1.2.0
قوانین
- محافظت از main با قوانین branch protection (PR اجباری، چکهای وضعیت)
- شاخههای feature کوتاهمدت (<= ۲ هفته)
- هر merge به main/release باید از طریق PR باشد
Pull Request و بازبینیها
بخش توضیحات کاملقالبهای PR
همیشه از قالب PR استفاده کنید: توضیحات، مراحل تست، چکلیست، issueهای مرتبط.
قوانین بازبینی
- نیاز به ۱–۲ تأیید بر اساس اثرگذاری
- اجرای CI و موفقیت قبل از merge
- PRهای کوچک (<۲۰۰ خط) ترجیح داده شوند
لیبلها و شاخهها
از لیبلها استفاده کنید: bug، enhancement، docs، chore. از لیبل WIP برای درحالتوسعه استفاده کنید.
استراتژیهای Merge
بخش توضیحات کاملاستراتژیهای رایج
- Merge commit: تاریخچهٔ شاخه را حفظ میکند؛ مناسب برای mergeهای release.
- Squash merge: همه تغییرات شاخه را به یک کامیت تبدیل میکند؛ برای تغییرات کوچک مناسب است.
- Rebase and merge: تاریخچهٔ خطی ایجاد میکند؛ در شاخههای مشترک با احتیاط استفاده شود.
سیاست
main را محافظت کنید: PR، CI و انتخاب روش merge مطابق سیاست سازمان. از force-push روی شاخههای مشترک خودداری کنید.
تگگذاری و ریلیز
بخش توضیحات کاملAnnotated در مقابل Lightweight
برای ریلیزهای تولید از تگهای annotated (و امضا شده) استفاده کنید تا متادیتا و امضا ذخیره شود.
نسخهگذاری
از SemVer استفاده کنید: MAJOR.MINOR.PATCH. برای پیشانتشارها از -rc و -beta و برای متادیتای بیلد از +build.
فرآیند ریلیز
- تگ از کامیت ریلیز یا artifact ساخته شده توسط CI
- ضمیمه کردن checksum و release notes
- ذخیرهٔ artifactها در ریجستری غیرقابل تغییر
یکپارچهسازی CI/CD
بخش توضیحات کاملاصول کلیدی
- بیلد از تگ یا artifact غیرقابل تغییر انجام شود
- تگهای ایجادشده توسط کاربران تاییدنشده قابل اعتماد نباشند — تگ نهایی توسط CI یا release manager ساخته شود
- SHA کامیت و متادیتای بیلد را در artifactها درج کنید
چکها
اجرای تستها، lint، اسکن امنیتی و بررسی لایسنس در PR و pipelineهای ریلیز ضروری است.
(.gitignore / LFS)
بخش توضیحات کامل.gitignore
.gitignore سطح مخزن و سراسری را نگه دارید. از commit کردن خروجیهای build و اسرار خودداری کنید.
Git LFS
برای فایلهای بزرگ از Git LFS استفاده کنید؛ آستانهٔ اندازهها را در سیاست مخزن تعیین کنید.
Hooks & Automation
بخش توضیحات کاملهوکهای کلاینت
هوکهای pre-commit برای lint، فرمتینگ و اسکن اولیهٔ اسرار. یک repo مشترک برای هوکها فراهم کنید.
هوکهای سرور
هوکهای سرور برای اعمال سیاست: جلوگیری از force-push، اطمینان از امضای کامیت، بررسی نام شاخهها.
Rebase در برابر Merge (توضیحات کامل)
بخش توضیحات کاملMerge
یک کامیت merge ایجاد میکند که توپولوژی شاخه را حفظ میکند. مزایا: تاریخچهٔ ادغام واضح؛ معایب: تاریخچه پیچیدهتر.
Rebase
کامیتها را روی یک بیس دیگر بازنویسی میکند و تاریخچهٔ خطی میسازد. مزایا: تاریخچهٔ تمیز؛ معایب: بازنویسی هشها — در شاخههای عمومی باید احتیاط شود.
چه زمانی از هرکدام استفاده کنیم
- برای شاخههای ریلیز و جایی که تاریخچهٔ ادغام مهم است از merge استفاده کنید
- برای پاکسازی محلی قبل از PR از rebase استفاده کنید تا تاریخچه خطی شود
- هرگز بدون هماهنگی شاخههای مشترک را rebase نکنید
مثالها
# merge git checkout main git merge feature/foo # rebase git checkout feature/foo git rebase main git checkout main git merge --ff-only feature/foo
Monorepo و مخازن بزرگ
بخش توضیحات کاملنکات
- نسخهبندی در سطح پکیج یا انتشار مبتنی بر دایرکتوری
- استفاده از shallow clone و sparse-checkout در CI
- تقسیم CI برای اجرای فقط ماژولهای تحت تاثیر
محافظت از شاخه
بخش توضیحات کاملقوانین
- پرداختن به PR و بررسیها
- نیاز به عبور CI
- محدود کردن افراد مجاز برای push/merge
- اختیاری: نیاز به کامیتهای امضا شده
چَنجلاگ و Release Notes
بخش توضیحات کاملتولید خودکار
از Conventional Commits برای تولید خودکار چَنجلاگ استفاده کنید. توضیحات PR و لینک issueها را درج کنید.
چکلیست بررسی کد
بخش توضیحات کامل- آیا تغییر تست دارد؟
- آیا API سازگار با گذشته است؟
- آیا مستندات بروز شده اند؟
- مسائل امنیتی بررسی شده؟
اتوماسیون: نگهداری و CI
بخش توضیحات کاملبهروزرسانی وابستگیها، فرمترها و نگهداری دورهای را با رباتها اتوماتیک کنید (dependabot, renovate).
خلاصه بهترین شیوهها
بخش توضیحات کامل- کامیتهای کوچک و پیامهای معنادار
- شاخههای محافظتشده و CI اجباری
- اتوماسیون برای آنچه قابل اتومات است
- محرمانهها از مخزن دور باشند
هوکهای کلاینت و سرور
بخش توضیحات کاملهوکهای استاندارد pre-commit را توزیع کنید، از pre-push و اعمال سروری برای پیادهسازی سیاست استفاده کنید. هوکها را در مخزن نگه دارید و اسکریپت نصب ارائه دهید.
امضا (GPG / SSH)
بخش توضیحات کاملدر صورت نیاز، کامیتها و تگها را امضا کنید. مدیریت مرکزی کلیدها توصیه میشود. CI بررسی امضاها را برای امنیت زنجیره تامین تقویت میکند.
دسترسی و نقشها
بخش توضیحات کاملنقشها را تعریف کنید: خواننده، توسعهدهنده، مدیر ریلیز، ادمین. اصل حداقل دسترسی را اجرا و دسترسی را دورهای بررسی کنید.
ساختار مخزن
بخش توضیحات کاملدایرکتوریهای استاندارد را تعریف کنید (src/, tests/, docs/, scripts/, ci/) و با قالبها اعمال کنید.