Conventional Commits یه روش ساده و استاندارد برای نوشتن پیام‌های کامیت هست که باعث میشه تاریخچه تغییرات پروژه همیشه واضح و مرتب بمونه. با این روش، شما می‌تونید به راحتی متوجه بشید که چه زمانی یه ویژگی جدید به پروژه اضافه شده، چه زمانی یه باگ اصلاح شده یا حتی چه زمانی تغییرات بزرگی باعث شکستن ساختار پروژه شده!
✅ چرا استفاده کنیم؟
تولید خودکار CHANGELOG
تعیین تغییرات نسخه به صورت خودکار
ارتباط واضح‌تر با تیم توسعه و مشارکت‌کنندگان
مدیریت پروژه به شیوه‌ای منظم و راحت‌تر
✅ساختار پیام کامیت:
[optional scope]:
[optional body]
[optional footer(s)]
✅انواع پیام‌ها:
fix: برای رفع باگ‌ها (معمولاً باعث تغییر در PATCH نسخه میشه).
feat: برای اضافه کردن ویژگی‌های جدید (این تغییرات باعث تغییر در MINOR نسخه میشه).
BREAKING CHANGE: وقتی که تغییری بزرگ و شکستن API توی کد اتفاق می‌افته (و باعث تغییر در MAJOR نسخه میشه).
انواع دیگه:
build: تغییرات در ابزارهای ساخت یا وابستگی‌ها.
chore: کارهایی که کد رو تغییر نمی‌ده ولی به پروژه مربوطه.
docs: تغییرات توی مستندات.
style: تغییرات ظاهری یا فرمت‌بندی بدون تغییر در رفتار کد.
refactor: تغییرات توی کد که بدون تغییر عملکرد کد انجام میشه.
perf: تغییرات برای بهبود عملکرد.
test: تغییرات در تست‌ها.
✅مثال‌ها:
1. اضافه کردن ویژگی جدید:
feat: پشتیبانی از زبان فارسی اضافه شد
2. تغییرات بزرگ:
feat!: تغییر در ساختار ذخیره‌سازی داده‌ها
BREAKING CHANGE: قالب ذخیره‌سازی داده‌ها تغییر کرده.
3. رفع باگ:
fix: مشکل بارگذاری تصاویر رفع شد
✅سوالات متداول:
حروف بزرگ یا کوچک؟ مهم اینه که یکپارچگی رو رعایت کنید، ولی به طور کلی حساس نیست.
ربط به SemVer؟
fix → PATCH
feat → MINOR
BREAKING CHANGE → MAJOR
این روش باعث میشه که تاریخچه پروژه مرتب و قابل فهم باشه و همکاری راحت‌تر انجام بشه
ترجمه:
If you work as a programmer or software developer with different teams, you must know that one of the biggest challenges can be managing the history of commits and understanding code changes. Sometimes, when we look at the past of the project, it is not clear what exactly the code changed and why these changes were applied! This is where Conventional Commits come in handy.
Conventional Commits is a simple and standard way to write commit messages, which makes the history of project changes always clear and orderly. With this method, you can easily find out when a new feature has been added to the project, when a bug has been fixed, or even when major changes have broken the project’s structure!
Why use it?
Automatic generation of CHANGELOG
Automatically determine version changes
Clearer communication with development team and contributors
Project management in a more organized and convenient way
Commit message structure:
[optional scope]:
[optional body]
[optional footer(s)]
Types of messages:
fix: to fix bugs (usually changes in PATCH version).
feat: to add new features (these changes will change the MINOR version).
BREAKING CHANGE: When a big change and breaking the API happens in the code (and causes a change in the MAJOR version).
Other types:
build: Changes to build tools or dependencies.
chore: tasks that do not change the code but are related to the project.
docs: Changes in documentation.
style: changes in appearance or formatting without changing the behavior of the code.
refactor: changes in the code that are made without changing the functionality of the code.
perf: Changes to improve performance.
test: changes in tests.
Examples:
1. Add a new feature:
feat: Persian language support was added
2. Major changes:
feat!: change in data storage structure
BREAKING CHANGE: The data storage format has changed.
3. Bug fixes:
fix: The problem of loading images has been fixed
Frequently asked questions:
Uppercase or lowercase? It is important to observe integrity, but it is not critical in general.
Related to SemVer?
fix → PATCH
feat → MINOR
BREAKING CHANGE → MAJOR
This method makes the history of the project orderly and understandable and makes collaboration easier
Conventional Commits is a simple and standard way to write commit messages, which makes the history of project changes always clear and orderly. With this method, you can easily find out when a new feature has been added to the project, when a bug has been fixed, or even when major changes have broken the project’s structure!
Why use it?
Automatic generation of CHANGELOG
Automatically determine version changes
Clearer communication with development team and contributors
Project management in a more organized and convenient way
Commit message structure:
[optional scope]:
[optional body]
[optional footer(s)]
Types of messages:
fix: to fix bugs (usually changes in PATCH version).
feat: to add new features (these changes will change the MINOR version).
BREAKING CHANGE: When a big change and breaking the API happens in the code (and causes a change in the MAJOR version).
Other types:
build: Changes to build tools or dependencies.
chore: tasks that do not change the code but are related to the project.
docs: Changes in documentation.
style: changes in appearance or formatting without changing the behavior of the code.
refactor: changes in the code that are made without changing the functionality of the code.
perf: Changes to improve performance.
test: changes in tests.
Examples:
1. Add a new feature:
feat: Persian language support was added
2. Major changes:
feat!: change in data storage structure
BREAKING CHANGE: The data storage format has changed.
3. Bug fixes:
fix: The problem of loading images has been fixed
Frequently asked questions:
Uppercase or lowercase? It is important to observe integrity, but it is not critical in general.
Related to SemVer?
fix → PATCH
feat → MINOR
BREAKING CHANGE → MAJOR
This method makes the history of the project orderly and understandable and makes collaboration easier
