কমিট করা — এটি কী, ফরম্যাটিং নিয়ম এবং Git-এর সাথে কাজ করা

Git-এ কমিট কী

Git-এ কমিট হল একটি অবজেক্ট যা একটি নির্দিষ্ট সময়ে প্রজেক্ট ফাইলের অবস্থা সংরক্ষণ করে। প্রতিটি কমিটে সমস্ত ট্র্যাক করা ফাইলের স্ন্যাপশট, প্যারেন্ট কমিটের রেফারেন্স এবং মেটাডেটা থাকে। অন্যান্য ভার্সন কন্ট্রোল সিস্টেমের বিপরীতে, Git কন্টেন্ট-অ্যাড্রেসেবল স্টোরেজ ব্যবহার করে — প্রতিটি অবজেক্ট তার বিষয়বস্তুর SHA-1 হ্যাশ দ্বারা চিহ্নিত হয়।

যখন একজন ডেভেলপার পরিবর্তন কমিট করে, Git একটি কমিট অবজেক্ট তৈরি করে যা সংরক্ষণ করে: ট্রি অবজেক্ট (ফাইল কাঠামো), প্যারেন্ট কমিট হ্যাশ, লেখক, কমিটার, তারিখ এবং বার্তা। এই অবজেক্টটি অপরিবর্তনীয় — তৈরি হওয়ার পর, কমিট তার হ্যাশ পরিবর্তন না করে সংশোধন করা যায় না। এই অপরিবর্তনীয়তা প্রজেক্টের ইতিহাসের অখণ্ডতা নিশ্চিত করে।

# পরিবর্তন স্টেজ করুন এবং কমিট করুন
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# কমিট বিবরণ দেখুন
git log --oneline -3
git show HEAD

# সব পরিবর্তন স্টেজ করুন এবং এক ধাপে কমিট করুন
git commit -a -m "Update dependencies to latest versions"

কমিটগুলি একটি নির্দেশিত অচক্রীয় গ্রাফ (DAG) গঠন করে, যেখানে প্রতিটি নতুন কমিট পূর্ববর্তীটিকে রেফারেন্স করে। এটি ইতিহাসে নেভিগেট করা, পরিবর্তন প্রত্যাহার করা এবং কোডবেসের বিবর্তন বিশ্লেষণ করার অনুমতি দেয়। Git DAG-এর কাঠামো বোঝা কমিট নিয়ে উন্নত কাজের ভিত্তি।

কীভাবে সঠিকভাবে পরিবর্তন কমিট করবেন

Git-এ কমিট প্রক্রিয়া দুটি ধাপ নিয়ে গঠিত: স্টেজিং এরিয়ায় (ইনডেক্স) পরিবর্তন যোগ করা এবং কমিট তৈরি করা। স্টেজিং এরিয়া ডেভেলপারকে নির্বাচন করতে দেয় যে কমিটে কোন নির্দিষ্ট পরিবর্তনগুলি অন্তর্ভুক্ত হবে, এমনকি ওয়ার্কিং ডিরেক্টরিতে অনেক ফাইল পরিবর্তিত হলেও।

পারমাণবিকতার নিয়ম একটি ভাল কমিটের মূল নীতি। প্রতিটি কমিটে একটি যৌক্তিক পরিবর্তন থাকা উচিত। যদি একজন ডেভেলপার বাগ ঠিক করে এবং কোড রিফ্যাক্টর করে — এগুলি দুটি আলাদা কমিট হওয়া উচিত। পারমাণবিক কমিট কোড রিভিউ, পরিবর্তন রোলব্যাক এবং ইতিহাস বিশ্লেষণ সহজ করে।

কমিট করার আগে, পরীক্ষা করা উচিত: কোডে কোনো ডিবগ আউটপুট, কমেন্ট করা ব্লক বা আকস্মিক পরিবর্তন বাকি আছে কিনা। এর জন্য git diff --cached কমান্ড ব্যবহার করা হয়, যা দেখায় যে কমিটে কী অন্তর্ভুক্ত হবে। git status-এর মাধ্যমে অতিরিক্ত পরীক্ষা স্টেজিং এরিয়ায় ফাইলের তালিকা প্রদর্শন করে।

• পরিবর্তন পরীক্ষা করুন — git diff --cached দেখায় কমিটে কী যাবে
• গুণমান পরীক্ষা করুন — কমিটের আগে কোডকে লিন্টার এবং টেস্ট পাস করতে হবে
• বার্তা লিখুন — পরিবর্তনের উদ্দেশ্যের স্পষ্ট বিবরণ
• স্টেজ করা ফাইল পরীক্ষা করুন — git status ফাইল তালিকা নিশ্চিত করে

কমিট বার্তা লেখার নিয়ম

কমিট বার্তা ভবিষ্যতের ডেভেলপারদের জন্য পরিবর্তনের ডকুমেন্টেশন। একটি ভাল বার্তা প্রশ্নের উত্তর দেয়: কী পরিবর্তন করা হয়েছে এবং কেন। Conventional Commits কনভেনশন (Angular টিম, 2016) অনেক প্রকল্পের জন্য মানদণ্ড হয়ে উঠেছে এবং বিন্যাস নির্ধারণ করে: প্রকার(ক্ষেত্র): বিবরণ।

একটি ভাল কমিট বার্তায় শিরোনাম (50 অক্ষর পর্যন্ত) এবং মূল অংশ (ঐচ্ছিক, প্রতি লাইনে 72 অক্ষর পর্যন্ত) থাকে। শিরোনাম imperative mood-এ লেখা হয়: “Add” নয় “Added” বা “Adds”। Capitalization এবং শিরোনামের শেষে পূর্ণবিরাম ব্যবহার করা হয় না — এটি একটি আন্তর্জাতিক Git কনভেনশন।

খারাপ বার্তা: “fix things” বা “update” — এটি কোনো তথ্য বহন করে না। এক মাসে, একজন ডেভেলপার বুঝতে পারবে না যে আসলে কী এবং কেন পরিবর্তন করা হয়েছিল। ভাল বার্তা: “fix(payment): handle timeout in stripe callback” — সঙ্গে সঙ্গেই স্পষ্ট হয় কী এবং কোথায় ঠিক করা হয়েছে।

কমিট করার সময় সাধারণ ভুল

ডেভেলপাররা, বিশেষ করে শিক্ষানবিশরা, প্রায়ই কমিট করার সময় সাধারণ ভুল করে থাকে। সবচেয়ে সাধারণ হল অতিরিক্ত বড় কমিট, যাতে ডজনখানেক পরিবর্তন মিশ্রিত থাকে। এই ধরনের কমিট আংশিকভাবে প্রত্যাহার করা যায় না, এবং কোড রিভিউ যন্ত্রণাদায়ক হয়ে ওঠে।

দ্বিতীয় সবচেয়ে সাধারণ ভুল হল খারাপ কমিট বার্তা। “fix”, “update”, “changes” বা “wip”-এর মতো বার্তা ভবিষ্যতের ডেভেলপারদের প্রসঙ্গ প্রদান করে না। ছয় মাসে, কেউ মনে রাখবে না যে আসলে কী ঠিক করা হয়েছিল। নিয়মটি সহজ: কল্পনা করুন যে এক বছর পরে আপনি ইতিহাস দেখছেন এবং একটি নির্দিষ্ট পরিবর্তন খুঁজে বের করার চেষ্টা করছেন।

তৃতীয় ভুল হল কম্পাইল না করা বা অকার্যকর কোড কমিট করা। কমিটের পরে, কোডকে অন্তত কম্পাইল হতে হবে। বিল্ড ভাঙ্গা নয় শেয়ার্ড ব্রাঞ্চে যেকোনো কমিটের জন্য একটি মৌলিক প্রয়োজনীয়তা। এর জন্য কমিটের আগে বিল্ড এবং টেস্ট চালানো হয়।

চতুর্থ ভুল হল গোপনীয় ডেটা কমিট করা। API কী, পাসওয়ার্ড এবং টোকেন Git ইতিহাসে যাওয়া উচিত নয়। যদি কোনো গোপনীয়তা ইতিমধ্যেই কমিট করা হয়ে থাকে, তবে তা নতুন কমিটে সরিয়ে ফেলাই যথেষ্ট নয়, বরং git filter-branch বা BFG Repo-Cleaner-এর মাধ্যমে পুরো ইতিহাস থেকে মুছে ফেলতে হবে।

কমিট নিয়ে কাজ করার উন্নত কৌশল

Git কমিট ইতিহাস ব্যবস্থাপনার জন্য সরঞ্জাম সরবরাহ করে। সবচেয়ে দরকারী একটি হল git commit --amend, যা শেষ কমিটকে নতুন পরিবর্তনের সাথে পরিপূরক করতে বা বার্তা সংশোধন করতে দেয়। এটি সুবিধাজনক যদি ডেভেলপার একটি ফাইল অন্তর্ভুক্ত করতে ভুলে যান বা বার্তায় টাইপিং ভুল করেন।

# শেষ কমিট বার্তা ঠিক করুন
git commit --amend -m "fix(auth): correct token validation logic"

# শেষ কমিটে ভুলে যাওয়া ফাইল যোগ করুন
git add missed-file.txt
git commit --amend --no-edit

# শেষ 3 কমিটের জন্য ইন্টারেক্টিভ রিবেস
git rebase -i HEAD~3

Interactive rebase ইতিহাস পুনর্লিখনের জন্য একটি শক্তিশালী সরঞ্জাম। এটি কমিট একত্রিত করতে (squash), বার্তা পরিবর্তন করতে (reword), পুনর্বিন্যাস করতে (reorder) এবং কমিট মুছতে (drop) দেয়। তবে, rebase ইতিহাস পরিবর্তন করে, তাই এটি শুধুমাত্র স্থানীয় কমিটগুলিতে ব্যবহার করা হয় যা এখনও রিমোট রিপোজিটরিতে পুশ করা হয়নি।

কমিট প্রত্যাহারের দুটি পদ্ধতি রয়েছে। git revert একটি নতুন কমিট তৈরি করে যা আগেরটির পরিবর্তনগুলি বাতিল করে — একটি নিরাপদ পদ্ধতি যা ইতিহাস সংরক্ষণ করে। git reset কমিটগুলিকে ইতিহাস থেকে মুছে ফেলে — বিপজ্জনক যদি কমিটগুলি ইতিমধ্যে পুশ করা হয়ে থাকে। টিম ডেভেলপমেন্টে, প্রকাশিত কমিট প্রত্যাহারের জন্য শুধুমাত্র git revert ব্যবহার করা হয়।