Conventional Commits ও commitlint অনুযায়ী একটি commit বার্তা যাচাই করুন, সঙ্গে এর ভার্সন বৃদ্ধি দেখুন
আপনার ব্রাউজারে চলে। আপনি যা লেখেন তা কোথাও পাঠানো হয় না। যাচাই করা হয়েছে 16 অক্টোবর, 2026।একটি conventional commit শুরু হয় একটি টাইপ, একটি ঐচ্ছিক scope এবং একটি বিবরণ দিয়ে, যেমন "fix(api): handle empty response"। একটি বার্তা পেস্ট করে commitlint-এর config-conventional-এর 12টি নিয়মে সেটি যাচাই করুন, এর অংশগুলো দেখুন এবং দেখুন এটি কোন রিলিজ বোঝায়: feat মানে minor, fix মানে patch, আর একটি ব্রেকিং পরিবর্তন মানে major।
এই পৃষ্ঠাটি ইংরেজি মূল লেখা থেকে যন্ত্রের সাহায্যে অনুবাদ করা হয়েছে। এই অনুবাদটি এখনও কোনো মানুষ পর্যালোচনা করেননি, তাই ইংরেজি সংস্করণটিকেই নির্ভরযোগ্য ধরুন। ইংরেজি মূল লেখাটি পড়ুন
commit বার্তাটি পেস্ট করুন, অথবা একটি শুরু করতে feat বা fix-এর মতো একটি টাইপে ট্যাপ করুন।
ফলাফল পড়ুন: যে প্রতিটি নিয়ম ভাঙা হয়েছে তা সহজ ভাষায়, এবং বার্তাটিকে যে অংশগুলোতে পড়া হয়েছে সেগুলো।
বার্তাটি পাস না করা পর্যন্ত ঠিক করুন; রিলিজ লাইনটি দেখায় এটি major, minor না patch ভার্সন বোঝায়।
পুরো একটি pull request-এর জন্য হেডারের একটি তালিকা-তে যান এবং git log --format=%s-এর আউটপুট পেস্ট করুন।
Conventional Commits হলো commit বার্তার একটি ছোট ফরম্যাট যা টুলগুলো পড়তে পারে: রিলিজ টুল এটি থেকে পরের ভার্সন নম্বর বেছে নেয়, আর changelog টুল এটিকে রিলিজ নোটে পরিণত করে। অনেক দল commit-msg hook-এ commitlint দিয়ে এটি বাধ্যতামূলক করে, এবং একটি প্রত্যাখ্যাত commit বার্তা একটি সাধারণ ছোট বিরক্তি।
ফরম্যাট। একটি হেডার, তারপর ঐচ্ছিক বডি ও ফুটার, প্রতিটি একটি ফাঁকা লাইন দিয়ে আলাদা:
| অংশ | উদাহরণ | নিয়ম |
|---|---|---|
| টাইপ | feat, fix, docs |
11টির একটি, ছোট হাতের অক্ষরে |
| Scope | (api) |
ঐচ্ছিক, বন্ধনীর মধ্যে |
| ব্রেকিং | কোলনের আগে ! |
অথবা একটি BREAKING CHANGE ফুটার |
| বিবরণ | add login page |
প্রথম অক্ষর ছোট হাতের, শেষে দাঁড়ি নয় |
| হেডারের দৈর্ঘ্য | সর্বোচ্চ 100 অক্ষর | |
| ফুটার | Closes #123 |
একটি ফাঁকা লাইনের পরে |
কী যাচাই করা হয়। @commitlint/config-conventional-এর বারোটি নিয়ম: দশটি ত্রুটি (টাইপ খালি, টাইপের কেস, টাইপের তালিকা, বিবরণ খালি, বিবরণের কেস, শেষে দাঁড়ি, হেডারের দৈর্ঘ্য, হেডারের স্পেস, বডি ও ফুটারের লাইনের দৈর্ঘ্য) এবং দুটি সতর্কতা (বডির আগে ও ফুটারের আগে একটি ফাঁকা লাইন)। প্রতিটি ব্যর্থতা সহজ ভাষায় সমাধানসহ ব্যাখ্যা করা হয়।
ভার্সন বৃদ্ধি। স্পেসিফিকেশনটি commit-গুলোকে Semantic Versioning-এর সঙ্গে মেলায়: fix মানে একটি patch রিলিজ, feat একটি minor, আর যেকোনো ব্রেকিং পরিবর্তন, যা ! বা একটি BREAKING CHANGE ফুটার দিয়ে চিহ্নিত, একটি major। docs বা chore-এর মতো অন্য টাইপ নিজে থেকে ভার্সন বদলায় না।
পুরো একটি pull request। তালিকা মোডে যান এবং git log --format=%s main..HEAD-এর আউটপুট পেস্ট করুন, প্রতি লাইনে একটি হেডার। প্রতিটি হেডার পাস বা ফেল করে, এবং সব মিলিয়ে যে রিলিজ হয় তার নাম দেখানো হয়।
উত্তরগুলো 100-এর বেশি বার্তায় config-conventional সহ @commitlint/lint 19-এর সঙ্গে মিলিয়ে দেখা হয়েছে। সবকিছু আপনার ব্রাউজারে চলে; আপনি যা টাইপ করেন তা কোথাও পাঠানো হয় না।
এমন একটি commit বার্তা যার প্রথম লাইনে থাকে একটি টাইপ, বন্ধনীর মধ্যে একটি ঐচ্ছিক scope, একটি কোলন, একটি স্পেস এবং একটি ছোট বিবরণ, যেমন fix(api): handle empty response। ফরম্যাটটি Conventional Commits 1.0.0 স্পেসিফিকেশন থেকে এসেছে, এবং টুলগুলো এটি ব্যবহার করে স্বয়ংক্রিয়ভাবে পরের ভার্সন নম্বর বেছে নেয় ও changelog লেখে।
ব্যবহারকারীরা নতুন সক্ষমতা হিসেবে দেখবেন এমন পরিবর্তনের জন্য feat, বাগ সংশোধনের জন্য fix, আর এর কোনোটিই বদলায় না এমন রক্ষণাবেক্ষণের জন্য chore ব্যবহার করুন, যেমন ডিপেন্ডেন্সি আপডেট। রিলিজ এগুলো থেকেই আসে: feat একটি minor ভার্সন দেয়, fix একটি patch, আর chore নিজে থেকে কোনো রিলিজ দেয় না। docs, style, refactor, perf, test, build এবং ci হলো অন্য স্ট্যান্ডার্ড টাইপ।
কোলনের আগে একটি বিস্ময়চিহ্ন দিন, যেমন feat(api)!: remove the v1 endpoints, অথবা একটি ফাঁকা লাইনের পরে এমন একটি ফুটার যোগ করুন যা BREAKING CHANGE: দিয়ে শুরু হয় এবং কী ভাঙছে তা বলে। যেকোনো একটিই টাইপ যা-ই হোক রিলিজকে major ভার্সন করে। দুটি একসঙ্গে ব্যবহার করা অনুমোদিত এবং প্রচলিত।
সাধারণত কারণ হেডারটি হুবহু type: description-এর সঙ্গে মেলে না, তাই commitlint কোনো টাইপ বা বিবরণ খুঁজে পায় না। সাধারণ কারণগুলো হলো কোলনের পরে স্পেস না থাকা, কোলনের আগে স্পেস থাকা, বড় হাতের বা অজানা টাইপ, অথবা কোনো টাইপই না থাকা। কোন অংশ ভুল পড়া হয়েছে তা দেখতে বার্তাটি এখানে পেস্ট করুন।
config-conventional-এ নয়: এর subject-case নিয়ম sentence case, start case, pascal case বা upper case-এ লেখা বিবরণ প্রত্যাখ্যান করে, তাই Add login ফেল করে আর add login পাস করে। backtick বা উদ্ধৃতিচিহ্নের মধ্যের লেখা এই নিয়মে উপেক্ষা করা হয়, তাই শুরুতে `Button`-এর মতো একটি নাম থাকলে সমস্যা নেই। যে দলগুলো বড় হাতের অক্ষর চায় তারা নিজেদের কনফিগে নিয়মটি বদলে নেয়।
না। ডিফল্টভাবে commitlint merge commit, git-এর লেখা revert, fixup! ও squash! commit, এবং শুধু একটি ভার্সন নম্বর এমন হেডার, যেমন 1.2.3 বা chore(release): 1.2.3, বাদ দেয়। এই পেজটিও একই বার্তাগুলো বাদ দেয় এবং তা জানায়, তাই এখানের যাচাই hook-এর মতো একই উত্তর দেয়।
হার ও নিয়ম বদলায়; কোনো অঙ্কের ওপর নির্ভর করার আগে সূত্রটি দেখে নিন।
এখনও আটকে আছেন? Conventional Commits চেকার সম্পর্কে প্রশ্ন করুন আর যিনি জানেন তিনিই উত্তর দিতে পারেন। কোনো অ্যাকাউন্ট লাগবে না।