Claude Code git hooks — নিরাপদ কমিট ও দ্রুত রিভিউয়ের জন্য

কেন কমিট-টাইম অটোমেশন গুরুত্বপূর্ণ\n\nবেশিরভাগ রিভিউ-যন্ত্রণার উৎস “কঠিন” কোড নয়। তা ছোট, এড়ানো যায় এমন ভুল — একটি ডিবাগ ফ্ল্যাগ অন রেখে দেওয়া, অনফর্ম্যাটেড ফাইল যে হৈচৈপূর্ণ ডিফ তৈরি করে, মিস করা টেস্ট আপডেট, অথবা কনফিগে ভুলবশত গোপন যোগ করা — যা একটি পরিষ্কার রিভিউকে ধীর ও বারবার প্রশ্নোত্তরে পরিণত করে।\n\nকমিট-টাইম অটোমেশন সেটা থামানোর সবচেয়ে সহজ জায়গা। যখন চেকগুলো ঠিক কমিট হওয়ার আগেই চলে, তারা এমন সময়ে সমস্যা ধরে যে পরিবর্তনটা এখনো আপনার মাথায় তাজা আছে। একটি ভুল ঠিক করতে কয়েক সেকেন্ড লাগে কারণ আপনি কাজের প্রসঙ্গে আগে থেকেই আছেন। এর বিপরীতে যদি এটি দুদিন পরে পুল রিকোয়েস্টে ধরা পড়ে, তখন আরও কমিট যোগ হয়ে গেছে এবং রিভিউয়ারকে জানতে হবে কি ঘটেছে।\n\nGit hooks এই জন্য ব্যবহারিক কারণ তারা লোকালি চলে, CI-এর অপেক্ষা ছাড়া। কিন্তু এগুলো জাদু নয়। হুকগুলো স্কিপ করা যায়, ভুল কনফিগার হতে পারে, বা মেশিনগুলোর মধ্যে অনিয়মিত হতে পারে যদি টিম এগুলো স্ট্যান্ডার্ডাইজ না করে। এগুলো নিজেরাই গুণগত মান নিশ্চিত করতে পারে না। এগুলোকে গার্ডরেইল ভাবুন, গেট নয়।\n\nহুকগুলো সবচেয়ে বেশি সাহায্য করে “রিভিউ ট্যাক্স” প্রতিরোধে — সেই পুনরাবৃত্ত, কম-মূল্যের ফিডব্যাক যা বারবার ফিরে আসে। সাধারণ উদাহরণ: টোকেন বলে মনে হওয়া সংবেদনশীল স্ট্রিং, ফর্ম্যাটিং/লিন্ট শব্দ, “আপনি কি সঠিক টেস্ট চালিয়েছেন?”-ধরনের চেক, এবং একটি ছোট কনটেক্সট সারাংশ যা রিভিউয়ারকে উদ্দেশ্য বুঝতে সাহায্য করে।\n\nএখানেই Claude Code git hooks ভালোভাবে ফিট করে: এগুলো বিরক্তিকর যাচাইকরণ কাজগুলো করতে পারে এবং ঠিক সেই মুহূর্তে একটি মানুষের মতো পড়তে সক্ষম সংক্ষিপ্ত কনটেক্সট যোগ করতে পারে।\n\nপ্রত্যাশা ঠিক করা জরুরি। লোকাল হুকগুলো দ্রুত ও পূর্বানুমেয় রাখুন যাতে মানুষ এগুলো ভালোবাসে না ঘৃণা করে। দ্রুত চেকগুলো আপনার ল্যাপটপে থাকা উচিত; ধীর চেকগুলো পরে হওয়া উচিত। একটি ভাল বিভাজন হলো কমিট-টাইমে কয়েক সেকেন্ড এবং CI-তে কয়েক মিনিট। যদি কোনো হুক নিয়মিত এত ধীর হয়ে যায় যে কেউ “skip” করতে বাধ্য হয়, তবে সেটা আপনার রেপোকে রক্ষা বন্ধ করে দেয়।\n\nসরল উদাহরণ: আপনি এক মডিউল পরিবর্তন করে কয়েকটি ফাংশন রিফ্যাক্টর করেছেন। অটোমেশন না থাকলে, রিভিউয়ার ৪০০ লাইন দেখে যে ঘোরানো হয়েছে, কোন টেস্ট কথা আসে না, এবং তাকে মৌলিক প্রশ্ন করতে হবে। কমিট-টাইম চেক হলে কমিট ফর্ম্যাটেড থাকে, প্রাসঙ্গিক টেস্ট সেট চালানো হয়েছে, এবং কমিট মেসেজে একটি সংক্ষিপ্ত সারাংশ আছে। রিভিউ তখন যেখানে হওয়া উচিত সেখানে শুরু হয়: ডিজাইন নিয়ে, ক্লিনআপ নিয়ে নয়।\n\n## Claude Code git hooks কী যোগ করে\n\nGit hooks সাধারণত হ্যাঁ/না নিয়মে থামে: “ফাইলটি ফর্ম্যাটেড কি?” বা “আপনি লিন্ট চালিয়েছেন কি?”। Claude Code একটু লিমিটেড জাজমেন্ট লেয়ার যোগ করতে পারে—স্টেজ করা ডিফ ও কয়েকটি সম্পর্কিত ফাইল পড়ে সিদ্ধান্ত নিতে পারে যা মানুষের রিভিউয়ের সাথে ভাল মানায়।\n\nClaude Code git hooks-এর মাধ্যমে, হুকটি শুধুমাত্র যে পরিবর্তন আপনি করেছেন তাই দেখতে পারে, পুরো রেপো নয়। এতে অটোমেশন আরও নির্বাচক হয়। এটি টাচ করা মডিউলগুলো, সম্পাদিত কনফিগ ফাইলগুলো, এবং নতুন এনভায়রনমেন্ট ভ্যারিয়েবলগুলোর দিকে বেশি ফোকাস করতে পারে, সব কমিটকে একটি সম্পূর্ণ বিল্ড মনে না করে।\n\nপ্রয়োজনীয় কাজগুলো যেখানে “ডিফ পড়ে চিন্তা করা”ই ফলপ্রসূ:\n\n- সম্ভাব্য সিক্রেট (API কী, টোকেন, প্রাইভেট কী) ফ্ল্যাগ করা, এমনকি যদি সেগুলো সামান্যভাবে অবিরাম বা লাইনে বিভক্ত থাকে।\n- প্রেক্ষাপটসহ ফর্ম্যাটিং enforcing করা—উদাহরণস্বরূপ কেবল স্টেজ করা ফাইলগুলোর উপর ফরম্যাটার চালানো এবং সতর্ক করা যখন একটি ফর্ম্যাটার বিশাল অপ্রাসঙ্গিক চেঞ্জ করবে।\n- কী পরিবর্তিত হয়েছে দেখে টেস্ট সাজেস্ট বা আবশ্যক করা (উদাহরণ: “আপনি payment লজিক পরিবর্তন করেছেন, এই ইউনিট টেস্টগুলো চালান”)—সবকিছু চালাতে বলার বদলে।\n- ডিফ থেকে একটি সংক্ষিপ্ত রিভিউয়ার সারাংশ জেনারেট করা: কী changed, কেন, ঝুঁকির এলাকাগুলো, এবং কি যাচাই করতে হবে।\n\nপ্রতিবন্ধকতা গুরুত্বপূর্ণ কারণ একটি ধীর হুকই হবে স্কিপ করা হুক। লক্ষ্যটা ছোট রাখুন: সাধারণ ভুলগুলো শুরুতেই ধরার জন্য গার্ডরেইল যোগ করুন, প্রতিটি কমিটে দ্বিতীয় CI তৈরি করবেন না।\n\n### গতি ও বিশ্বাসযোগ্যতা প্রথমে\n\nএকটি ভাল নিয়ম: যদি কোনো চেক কয়েক সেকেন্ডে শেষ করতে না পারে, সম্ভবত এটি CI বা pre-push-এ থাকা উচিৎ। অনেক টিম দ্রুত লোকাল চেক চালায় কমিট-টাইমে এবং ভারী টেস্ট সুইটগুলো পরে চালায়।\n\nব্যর্থতা মোডের জন্য পরিকল্পনা রাখুন। যদি কোনো মডেল কল টাইমআউট করে, কমিট ব্লক করবে নাকি একটি সরল চেক-এ fallback করবে তা ঠিক করুন। একটি fallback ওয়ার্কফ্লো পূর্বানুমেয় রাখে এবং মানুষকে হুক ডিজেবল করতে প্রশিক্ষিত হওয়া রোধ করে।\n\n### প্রাইভেসি ও অনলাইন বনাম অফলাইন\n\nকিছু সেটআপ হোস্টেড মডেল কল করে; অন্যগুলো আরও বিচ্ছিন্ন পরিবেশে চলে। নির্ধারণ করুন কোন কোড ডেভেলপার মেশিন থেকে বাইরে যাবে (যদি কিছুই যায়), এবং আপনি কতটুকু পাঠাবেন তা সীমাবদ্ধ করুন। স্টেজ করা ডিফ প্লাস কয়েকটি রেফারেন্স ফাইল প্রায়ই যথেষ্ট।\n\nযদি আপনি সংবেদনশীল রেপোতে কাজ করেন, স্পষ্ট করুন কোথায় বিশ্লেষণ চলছে এবং কি লগ হচ্ছে। একটি বাস্তব উদাহরণ: যদি কমিটে নতুন কনফিগ ভ্যালু আসে যেমন STRIPE_SECRET=..., হুকটি কমিট रोकতে পারে, কি ঝুঁকিপূর্ণ দেখাচ্ছে ব্যাখ্যা করতে পারে, এবং পরামর্শ দিতে পারে সেটি সিক্রেট ম্যানেজারে বা লোকাল এনভি ফাইলে স্থানান্তর করার—এভাবে সেটা কখনো রিমোট রেপোতে পৌঁছবে না।\n\n## সঠিক হুক বেছে নিন ও দ্রুত রাখুন\n\nGit hooks তখনই কাজে লাগে যখন মানুষ এগুলো চালু রাখে ও কমিটকে কষ্টকর মনে না করে। ট্রিক হল: সঠিক কাজের জন্য সঠিক হুক বেছে নেওয়া এবং সব ধীর জিনিসগুলো হট-পাথ থেকে দূরে রাখা।\n\nচেকগুলো সাধারণত কোথায় থাকা উচিত তার সরল মানচিত্র:\n\n- pre-commit: দ্রুত, লোকাল চেক যা স্পষ্ট সমস্যাগুলো ব্লক করে (ফর্ম্যাটিং, সিক্রেট স্ক্যান, দ্রুত লিন্ট)\n- commit-msg: কেবল মেসেজ দরকার এমন চেক (টিকেট ID, দৈর্ঘ্য, কনভেনশনাল ফরম্যাট)\n- pre-push: ধীর তবে শেয়ার্ড রেপোতে যাওয়ার আগে ধরার মতো কাজ (ধীর টেস্ট, টাইপ চেক, বিল্ড)\n\nClaude Code git hooks যোগ করলে, এগুলোকে তাত্ক্ষণিকভাবে উপস্থিত হওয়া সহায়ক রিভিউয়ার হিসেবে ভাবুন, যেন ব্যাটলনেক নয়। নেটওয়ার্ক কল, পূর্ণ টেস্ট সুইট, বা দীর্ঘ বিশ্লেষণ যা প্রয়োজন সেগুলো pre-push বা CI-তে রাখুন, না যে pre-commit-এ।\n\nচেকগুলো কোথায় চলবে সিদ্ধান্ত নেওয়ার একটি ব্যবহারিক উপায় হলো গতি ও প্রভাব অনুযায়ী সোর্ট করা। যদি এটি উচ্চ-ঝুঁকির ইস্যু ধরতে পারে (যেমন লিক হওয়া কী) এবং কয়েক সেকেন্ডে চালানো যায়, pre-commit-এ রাখুন। যদি এটি 30–90 সেকেন্ড নেয়, pre-push-এ সরান বা কেবল নির্দিষ্ট ফাইল পরিবর্তন হলে চালান।\n\nটিমগুলোকে এনফোর্সমেন্ট নিয়ে স্পষ্ট মনোভাব দরকার। সিঙ্গেল-ডেভেলপার রেপোতে opt-in হুক ঠিক আছে। টিম রেপোতে সাধারণত বেসিক এনফোর্স করা হয় (সিক্রেটস, ফর্ম্যাটিং, কমিট মেসেজ নিয়ম) এবং ভারী চেকগুলো লোকালি পরামর্শমূলক রাখা হয়, যখন CI চূড়ান্ত গেট হিসেবে থাকে।\n\nহুক আউটপুট প্রত্যাশিতভাবেই গুরুত্বপূর্ণ। একটি ব্যর্থ হুক বলে দেবে কি হয়েছে এবং পরবর্তী কি করব। বার্তাগুলো সংক্ষিপ্ত ও নির্দিষ্ট রাখুন। সম্ভব হলে এক্স্যাক্ট ফাইল ও লাইন দেখান, এক স্পষ্ট ফিক্স কমান্ড দিন, জরুরি ক্ষেত্রে কিভাবে বাইপাস করতে হয় সেটা ব্যাখ্যা করুন (এবং কখন নয়), এবং বড় লগ দেখাবেন না যতক্ষণ না ব্যবহারকারী “verbose” চান।\n\nউদাহরণ: আপনি Koder.ai থেকে একটি প্রজেক্ট এক্সপোর্ট করে লোকালি কমিট করতে শুরু করলে, একটি দ্রুত pre-commit হুক কপি করা API টোকেনকে অবিলম্বে ধরতে পারে, আর pre-push ধীরে “শুধু পরিবর্তিত মডিউলগুলোর জন্য টেস্ট” নিয়ম চালায় আগে কেউ ব্রাঞ্চ দেখে।\n\n## কমিট হওয়ার আগে সিক্রেট ব্লক করুন\n\nএকটি সিক্রেট হলো এমন কিছু যা কাউকে আপনার মতো আচরণ করতে দেয় বা প্রাইভেট সিস্টেম অ্যাক্সেস করতে দেয়। ভাবুন API টোকেন, OAuth ক্লায়েন্ট সিক্রেট, ক্লাউড কী, ডাটাবেস পাসওয়ার্ড, প্রাইভেট ওয়েবহুক URL, সাইনিং কী, এমনকি “টেম্পরারি” টেস্ট ক্রিডেনশিয়ালও। একটি একঘণ্টার ভুল কমিট একটি fork, CI লগ, বা কপি করা ডিফে পৌঁছে যেতে পারে, এবং তখন সেটা আর টেম্পরারি থাকে না।\n\nসহজতম জয় হলো কেবল আপনি যা কমিট করতে যাচ্ছেন সেটাই স্ক্যান করা। একটি হুক স্টেজ করা পরিবর্তন (ইনডেক্স) চেক করা উচিত, পুরো রেপো নয়। এতে দ্রুততা থাকে এবং পুরনো ফাইল থেকে শব্দ উঠে আসে না—এবং প্রতিক্রিয়া ন্যায়সঙ্গত হয়: “এই কমিটে সমস্যা আছে” না যে “আপনার রেপোতে কখনও সমস্যা ছিল”।\n\nশুরুতেই ফ্ল্যাগ করা সাধারণ জিনিসগুলোর মধ্যে আছে: উচ্চ-এন্ট্রপি টোকেন (দীর্ঘ র‍্যান্ডম-দেখানো স্ট্রিং), পরিচিত কী ফর্ম্যাট (AWS কী, GitHub টোকেন, JWT), কনফিগে password=... বা api_key: ... মেলে এমন প্যাটার্ন, প্রাইভেট ক্রেডেনশিয়াল সহ URL, এবং .env ফাইল বা প্রোডাকশনের কপি করা কনফিগ।\n\nফলস পজিটিভ ঘটে, বিশেষ করে টেস্ট ডেটা, হ্যাশ, বা উদাহরণ ডক্সে। একটি allowlist রাখুন যাতে মানুষ পুরো চেক ডিজেবল না করে এগিয়ে যেতে পারে। allowlist থাকবে সংকীর্ণ: ফিক্সচারের জন্য নির্দিষ্ট ফাইল পাথ, অথবা স্পষ্ট মার্কার যেমন “dummy” বা “example” যা আপনার ডিটেক্টর চেনে।\n\nযখন সিক্রেট পাওয়া যায়, কমিটটি ব্যর্থ করুন এবং মানুষকে পরবর্তী কি করতে হবে তা বলুন। Claude Code git hooks এটাকে আরও বন্ধুত্বপূর্ণ করে একটি সংক্ষিপ্ত ব্যাখ্যা দিয়ে based on diff, কিন্তু মূল বিষয় হলো স্পষ্ট, নিরাপদ পরবর্তী পদক্ষেপগুলো: