📝 راهنمای پیشوندهای پیام Commit در Git

استفاده از پیشوند در پیام‌های Commit کمک می‌کند فقط با دیدن عنوان Commit بفهمیم چه تغییری در پروژه انجام شده است.

این روش بر اساس استاندارد Conventional Commits است و باعث می‌شود تاریخچه Git مرتب‌تر، خواناتر و قابل‌فهم‌تر باشد.

---

⚡ مرجع سریع

پیشوند	چه زمانی استفاده کنیم؟
feat	وقتی قابلیت جدید اضافه کرده‌ایم
fix	وقتی یک باگ را برطرف کرده‌ایم
chore	برای کارهای جانبی و نگهداری پروژه
docs	وقتی فقط مستندات تغییر کرده‌اند
style	تغییر فرمت و ظاهر کد بدون تغییر منطق
refactor	تغییر ساختار کد بدون تغییر رفتار
perf	برای بهتر کردن Performance
test	اضافه یا اصلاح کردن تست‌ها
build	تغییر Build، Dependencies یا ابزارهای Build
ci	تغییر تنظیمات CI/CD
revert	برگرداندن تغییرات یک Commit قبلی

---

📚 توضیحات و مثال‌ها

✨ feat

وقتی یک قابلیت جدید به پروژه اضافه می‌کنیم.

مثلاً:

• اضافه کردن Login
• اضافه کردن Dark Mode
• اضافه کردن صفحه کاربران
• اضافه کردن Search

مثال:

feat: add dark mode support

اگر بخواهیم مشخص کنیم تغییر مربوط به کدام بخش است:

feat(auth): add login with OTP

---

🐛 fix

وقتی یک باگ یا مشکل موجود را برطرف می‌کنیم.

مثلاً:

• رفع مشکل Login
• رفع Crash برنامه
• رفع نمایش اشتباه اطلاعات
• رفع مشکل Validation فرم

مثال:

fix: prevent crash on application startup

مثال با Scope:

fix(auth): resolve login redirect issue

---

🔧 chore

برای کارهای جانبی و نگهداری پروژه که معمولاً قابلیت جدیدی به برنامه اضافه نمی‌کنند.

مثلاً:

• آپدیت پکیج‌ها
• حذف فایل‌های اضافی
• تغییر تنظیمات ابزارها
• مرتب کردن تنظیمات پروژه

مثال:

chore: update project dependencies

یا:

chore: remove unused files

---

📖 docs

وقتی فقط مستندات پروژه تغییر می‌کنند.

مثلاً:

• تغییر README
• اضافه کردن توضیحات API
• اضافه کردن راهنمای نصب
• اصلاح Documentation

مثال:

docs: add installation guide to README

یا:

docs(api): add authentication examples

---

🎨 style

وقتی فقط فرمت و ظاهر کد تغییر می‌کند و منطق برنامه هیچ تغییری نمی‌کند.

مثلاً:

• اجرای Prettier
• اصلاح Indentation
• حذف فاصله‌های اضافی
• مرتب کردن فرمت کد

مثال:

style: format code with Prettier

style معمولاً برای تغییر UI یا CSS استفاده نمی‌شود؛ منظور اصلی تغییر Style خود کد بدون تغییر رفتار برنامه است.

---

♻️ refactor

وقتی ساختار کد را بهتر می‌کنیم ولی رفتار برنامه تغییر نمی‌کند.

مثلاً:

• ساده کردن یک Function
• جدا کردن Logic به Hook
• حذف کدهای تکراری
• تغییر ساختار Componentها

مثال:

refactor: simplify authentication logic

یا:

refactor(user): extract user logic into custom hook

---

⚡ perf

وقتی تغییری برای بهبود سرعت یا Performance برنامه انجام می‌دهیم.

مثلاً:

• کاهش درخواست‌های API
• بهینه کردن Query دیتابیس
• کاهش Re-render
• Lazy Load کردن بخش‌های برنامه

مثال:

perf: reduce unnecessary component re-renders

یا:

perf(api): cache user requests

---

🧪 test

وقتی تست جدید اضافه می‌کنیم یا تست‌های قبلی را تغییر می‌دهیم.

مثلاً:

• Unit Test
• Integration Test
• Browser Test
• اصلاح تست خراب

مثال:

test: add login form validation tests

یا:

test(auth): add tests for login flow

---

📦 build

برای تغییراتی که مربوط به Build پروژه یا Dependencies هستند.

مثلاً:

• تغییر Vite
• تغییر Webpack
• اضافه یا حذف Dependency
• تغییر Dockerfile مربوط به Build

مثال:

build: upgrade Vite to version 8

یا:

build: add react-query dependency

---

🚀 ci

برای تغییرات مربوط به CI/CD استفاده می‌شود.

مثلاً:

• تغییر GitHub Actions
• تغییر GitLab CI
• تغییر Pipeline
• تغییر مراحل Build و Deploy

مثال:

ci: add automated test stage

یا:

ci: update GitLab deployment pipeline

---

⏪ revert

وقتی می‌خواهیم تغییرات یک Commit قبلی را برگردانیم.

مثال:

revert: revert "feat: add dark mode support"

یعنی تغییر مربوط به اضافه شدن Dark Mode برگردانده شده است.

---

🎯 ساختار پیشنهادی Commit

بهتر است پیام Commit تا جای ممکن کوتاه، واضح و مشخص باشد.

ساختار ساده

<type>: <description>

مثال:

feat: add user profile page

ساختار با Scope

اگر بخواهیم مشخص کنیم تغییر مربوط به کدام بخش پروژه است:

<type>(<scope>): <description>

مثال:

feat(auth): add OTP login
fix(user): resolve profile image upload issue
refactor(api): simplify request handler
test(login): add validation tests

---

✅ چند نمونه واقعی

Frontend

فرض کنیم روی یک پروژه Frontend کار می‌کنیم:

feat(auth): add login page

fix(auth): resolve invalid token redirect

feat(user): add profile page

refactor(user): extract profile form logic into hook

test(auth): add login validation tests

style: format project with Prettier

chore: update dependencies

build: upgrade Vite

ci: add test stage to GitLab pipeline

docs: update project setup instructions

---

Backend

فرض کنیم روی یک پروژه Backend کار می‌کنیم:

feat(auth): add user login API

fix(auth): resolve token expiration issue

feat(user): add user profile endpoint

feat(user): add update profile API

refactor(auth): simplify authentication service

refactor(user): move user validation into service

test(auth): add login API tests

test(user): add user profile endpoint tests

perf(database): optimize user queries

fix(database): resolve duplicate user creation issue

build: update backend dependencies

chore: remove unused packages

ci: add backend test stage to GitLab pipeline

docs(api): add authentication endpoints documentation

---

🧩 نمونه Scope در Backend

در پروژه‌های Backend معمولاً scope می‌تواند نام بخش یا ماژول پروژه باشد.

مثلاً:

auth
user
product
order
payment
database
api
notification

اضافه کردن API ساخت محصول

feat(product): add create product API

رفع باگ پرداخت

fix(payment): resolve failed transaction status

بهینه‌سازی Queryهای سفارش

perf(order): optimize order queries

---

✅ جمع‌بندی

با رعایت این ساختار، Git History پروژه خیلی مرتب‌تر می‌شود و فقط با دیدن پیام هر Commit می‌توان فهمید:

• چه نوع تغییری انجام شده
• تغییر مربوط به کدام بخش پروژه بوده
• آیا قابلیت جدید اضافه شده یا باگی رفع شده
• آیا تغییر مربوط به تست، Build، CI/CD یا مستندات بوده

در نتیجه بررسی Commitها، Code Review و پیدا کردن تغییرات پروژه بسیار راحت‌تر می‌شود.

📄 License

Copyright © 2026 moreza-kaze. All Rights Reserved.

این محتوا بدون اجازه کتبی صاحب اثر قابل کپی وتغییر در پروژه‌های دیگر نیست.