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, কিন্তু মূল বিষয় হলো স্পষ্ট, নিরাপদ পরবর্তী পদক্ষেপগুলো:

ERROR: Possible secret detected in staged file: config/app.yaml (line 12)
Reason: looks like an API token
Next steps:
1) Remove it from the change or move it to env vars
2) Rotate the token (assume it is compromised)
3) Re-stage and retry commit
If this is a false positive, add a narrow allowlist rule in .secrets-allowlist
```\n\nএকটি বাস্তব উদাহরণ: কেউ ব্যাকএন্ড কনফিগ আপডেট করে এবং `TEMP_API_KEY` যোগ করে যাতে ফিচার dev-এ কাজ করে। হুক কমিট থামায়, সেটি এনভায়রনমেন্ট ভ্যারিয়েবলে স্থানান্তর করার পরামর্শ দেয়, এবং মনে করিয়ে দেয় টোকেনটি যদি আসল হয়ে থাকে তাহলে রোটেট করতে হবে। এটা একটি ছোট বিরতি, যা পরে বড় ক্লিনআপ আটকায়।\n\n## ফর্ম্যাটিং enforcing করুন কিন্তু মানুষকে ধীরে করবেন না\n\nফর্ম্যাটিং লড়াই রিভিউয়ারদের সময় নষ্ট করে, কিন্তু ধীর হুকগুলো হুক ডিসএবল করিয়ে দেয়। স্যুট স্পট হল সহজ নিয়ম, প্রতি ভাষায় একটি টুল, এবং কেবল স্টেজ করা অংশগুলোর উপর কাজ করা।\n\nপ্রতি ভাষায় একটি ফর্ম্যাটার বেছে নিন এবং সেটাকে সত্যের উৎস বানান। দুইটি ফর্ম্যাটার বা একটি ফর্ম্যাটার এবং একটি রিরাইটিং লিন্ট একে অপরের সঙ্গে দ্বন্দ্ব করলে শব্দ ও অনাবশ্যক চেঞ্জ হবে। একে সাধারণ রাখুন: একটি JS/TS ফর্ম্যাটার, একটি Go ফর্ম্যাটার, একটি Dart ফর্ম্যাটার। তারপর নিশ্চিত করুন সবাই একই ভার্সন চালায় যাতে হুক আউটপুট মেশিনভেদে স্থির থাকে।\n\nসবচেয়ে বড় গতি-বিশয় হল কেবল স্টেজ করা ফাইলগুলো ফর্ম্যাট করা। প্রতিটি কমিটে পুরো রেপো ফর্ম্যাট করা প্রি-কমিট নিয়ে অভিযোগ করার প্রধান কারণ। স্টেজ-ওনলি পদ্ধতি ডিফকেও সেই ফোকাস রাখে—যেটাই রিভিউয়ার চাইবে।\n\nদ্রুত রাখতে কাজের কিছু চয়েস:

- স্টেজ করা ফাইলগুলোর উপরই ফর্ম্যাটিং চালান।
- নিরাপদ পরিবর্তনগুলোর জন্য auto-fix ব্যবহার করুন (স্পেসিং, কোটস, ইমপোর্ট অর্ডার)।
- যেখানে মানব সিদ্ধান্ত দরকার সেখানে দ্রুত ফেল করুন।
- ফর্ম্যাটার পরিবর্তন হলে আলতো আউটপুট দেখান, নীরব রাখুন যতক্ষণ কিছু পরিবর্তন না হয়।
- যেখানে সম্ভব ক্যাশ ব্যবহার করুন, কিন্তু কখনই সঠিকতার খরচে নয়।\n\nAuto-fix বনাম ফেল—টিম পছন্দ অনুসারে। মেশিনিয়াল এডিটের জন্য auto-fix শ্রেষ্ঠ, কারণ তা “কমিট, ফেল, পুনরায় চালাও, আবার কমিট” লুপ এড়ায়। ফেল ভাল হতে পারে যখন আপনি চান মানুষ বিষয়টি দেখে সিদ্ধান্ত নিক। যদি আপনি ফেল করে দেন, একটি সহজ নির্দেশ দিন যেটা যেকেউ 10 সেকেন্ডে অনুকরণ করতে পারে।\n\nক্রস-প্ল্যাটফর্ম শব্দ দূর করার জন্য ছোট ছোট বিষয়গুলো স্ট্যান্ডার্ডাইজ করুন। লাইন-এন্ডিং ও ট্রেইলিং ওয়াইটস্পেস প্রাথমিক অভিযোগকারীরা।\n\nসহজ নীতি যা কম কষ্ট দেয়:

- রেপোতে LF লাইন-এন্ডিং বাধ্যতামূলক করুন।
- পরিবর্তিত লাইনে ট্রেইলিং ওয়াইটস্পেস সরিয়ে ফেলুন।
- ফাইলগুলো নিউলাইন দিয়ে শেষ করুন।
- জেনারেটেড ফাইল ও ভেন্ডর ডিরেক্টরি স্কিপ করুন।\n\nClaude Code git hooks এখানে সাহায্য করে glue হিসেবে: কোন স্টেজ করা ফাইলকে কোন ফর্ম্যাটার দরকার তা ডিটেক্ট করা, সঠিক ক্রমে চালানো, এবং ব্যর্থতা সহজ ভাষায় ব্যাখ্যা করা। উদাহরণস্বরূপ, কেউ স্টেজ করেছে একটি Go ফাইল ও একটি TS ফাইল—হুক প্রতিটি সঠিক টুল দিয়ে ফর্ম্যাট করে, রেজাল্ট রি-স্টেজ করে, এবং তারপর ছোট একটি নোট আউটপুট করে “2 files reformatted, no behavior changes” টাইপের — রিভিউয়ার পরিষ্কার ডিফ পায় এবং ডেভেলপার বারবার কমিট করতে কষ্ট পান না।\n\n## টাচ করা জিনিসের জন্য টেস্ট বাধ্যতামূলক করুন\n\nএকটি সহজ নিয়ম কমিটগুলোকে নিরাপদ করে দেয় ব্যথাহীনভাবে: কেবল আপনি স্টেজ করা অংশের সাথে মিল আছে এমন টেস্টগুলোই চালান। যখন হুক স্টেজ করা ডিফ দেখে (আপনার ওয়ার্কিং ট্রি নয়), এটি অসম্পূর্ণ ফাইল থেকে ভুল এলার্ম এড়ায়।\n\nপ্রথমে কোন এলাকা টাচ হয়েছে সেটা ডিটেক্ট করুন। বেশিরভাগ রেপোতে ইতিমধ্যেই একটি প্রাকৃতিক স্ট্রাকচার আছে: প্যাকেজ, সার্ভিস, অ্যাপ বা মডিউল। একটি হুক `git diff --cached --name-only` পড়ে সেই পাথগুলোকে ছোট টেস্ট কমান্ডের সেটে ম্যাপ করতে পারে।\n\nকিছু ম্যাপিং নিয়ম যা পরে বোঝার সময়ও সহজ থাকে:

- `web/` বা `frontend/` -> `npm test` (বা আপনার ছোট টার্গেটেড কমান্ড)
- `api/` বা `server/` -> ব্যাকএন্ড ইউনিট টেস্ট (ডিফল্টে ইন্টিগ্রেশন স্কিপ)
- `mobile/` -> দ্রুত উইজেট/ইউনিট টেস্ট, না ফুল ডিভাইস সুইট
- `db/` বা `migrations/` -> মাইগ্রেশন লিন্ট + ছোট স্কিমা চেক
- `shared/` -> শেয়ার্ড প্যাকেজ টেস্ট, প্লাস যে কনজিউমারগুলো দ্রুত যায় তাদের টেস্ট

Claude Code git hooks থাকলে, আপনি এক ধাপ এগোতে পারেন: Claude স্টেজ করা ফাইলনামগুলো দেখে একটি মিনিমাল টেস্ট সেট প্রস্তাব করতে পারে, তারপর হুক সেই কমান্ডগুলো চালায়। শেষ সিদ্ধান্ত নিয়মভিত্তিক রাখুন যাতে টিম ভবিষ্যতে পূর্বানুমেয় থাকতে পারে।\n\nকমিট ও পুশের মধ্যে কাজ ভাগ করুন। কমিটগুলো দ্রুত থাকা উচিত যাতে মানুষ হুক বাইপাস না করে। একটি বাস্তব ধাঁচ হল:

- কমিটে: দ্রুত, নির্বাচিত সেট চালান (লিন্ট + টাচ করা মডিউলগুলোর ইউনিট টেস্ট)
- পুশে: বিস্তৃত সেট চালান (ইন্টিগ্রেশন, ই২ই স্মোক, ক্রস-মডিউল টেস্ট)
- CI-তে: পুরো সুইট চালান ও কভারেজ গেট এনফোর্স করুন

ফ্লেকি ও ধীর টেস্টগুলোর জন্য স্পষ্ট পলিসি দরকার, নাহলে হুক শব্দ হয়ে যাবে। টিম মিলে ঠিক করুন কি ব্লক করবে কমিট আর কি কেবল ওয়ার্ন করবে। একটি কাজযোগ্য পদ্ধতি হলো স্পষ্ট ব্যর্থতার উপর ব্লক করা (ফর্ম্যাটিং, সাধারণভাবে স্থিতিশীল ইউনিট টেস্ট), পরিচিত ফ্লেকি টেস্টে ওয়ার্ন করা, এবং ধীর সুইটগুলো পুশ/CI-তে রাখা। যদি কোনো টেস্ট ফ্লেকি হয়, সেটাকে বাগ হিসেবে ট্র্যাক করুন ও দ্রুত ঠিক করুন।\n\n## কমিট টাইমে সংক্ষিপ্ত রিভিউয়ার সারাংশ জেনারেট করুন\n\nএকটি ভাল ডিফ সবসময় সহজে রিভিউ হয় না। একটি ছোট কমিট-টাইম সারাংশ 10-মিনিট পড়াকে 2-মিনিট চেক বানাতে পারে, বিশেষ করে যখন পরিবর্তন গুলো বহু ফাইল ছুঁয়েছে বা রিফ্যাক্টর আছে।\n\nধারণাটি সরল: যখন আপনি `git commit` চালান, আপনার হুক Claude Code-কে স্টেজ করা ডিফ পড়ে 3–6 লাইনের একটি নোট তৈরির জন্য বলুন যা রিভিউয়ারদের সবসময় যে প্রশ্নগুলো থাকে তাদের উত্তর দেয়: কী পরিবর্তিত, কেন, ঝুঁকি কত, এবং কী টেস্ট চালানো হয়েছে।\n\n### একটি সরল সারাংশ টেমপ্লেট\n\nআউটপুটটি টাইট ও কনসিস্টেন্ট রাখুন যাতে রিভিউয়াররা এটাকে ভরসাযোগ্য মনে করে:

- **What:** প্রধান পরিবর্তনের এক বাক্য (ফাইল তালিকা নয়)
- **Why:** ব্যবহারকারীর সমস্যা বা বাগ যা ঠিক করা হয়েছে
- **Risk:** low, medium, বা high এবং একটি কারণ
- **Testing:** আপনি যা চালিয়েছেন (অথবা বলুন “not run”)\n- **Notes:** মাইগ্রেশন, ফ্ল্যাগ, রোলআউট ধাপ, বা যে কোনও রিভিউ-ক্রীটিকাল বিষয়

এটি সরাসরি কমিট মেসেজে রাখতে পারেন (উদাহরণস্বরূপ, একটি শর্ট ফুটার হিসেবে), অথবা একটি ফাইল হিসেবে সেভ করে দলটি PR ডেসক্রিপশনে কপি করতে পারে। কমিট মেসেজ ভাল কাজ করে যখন আপনি চান কনটেক্সট পরিবর্তনের সাথে রয়ে যাক। আলাদা ফাইল ভাল যখন দল ক্লিন, কনভেনশনাল কমিট সাবজেক্ট রাখতে চায়।\n\n### সারাংশে সিক্রেট ফাঁস করবেন না\n\nএকটি সারাংশ টুল রিভিউয়ার থেকেও বেশি কঠোর হওয়া উচিত। মডেলে কোনো ডিফ কনটেন্ট পাঠানোর আগে সেই লাইনের মতো প্যাটার্ন(গুলি) রেড্যাক্ট করুন: API কী, প্রাইভেট কী, টোকেন, `.env` ভ্যালু এবং ক্রেডেনশিয়াল। আপনার রেপো যদি ক্যাপচার করা HTTP ট্রাফিক থাকে তাহলে সাধারণ হেডার ও কুকি ও ফিল্টার করুন। যখন হুক সংবেদনশীল প্যাটার্নগুলো পায়, লাইনে রেড্যাক্ট করতে পারে বা জেনেরিক সারাংশে fallback করতে পারে যেমন “credentials-related changes redacted”。\n\nউদাহরণ: আপনি একটি বিলিং এন্ডপয়েন্ট আপডেট করেছেন এবং তিনটি файл টাচ করেছেন। স্টেজ করা ডিফ রিনেমের কারণে গোলমালপূর্ণ, কিন্তু সারাংশ বলে: “Adds idempotency key handling for charge creation to prevent double billing. Reason: retries caused duplicate charges. Risk: medium (payment path). Testing: unit tests for billing service, manual request replay.” — ঠিক যে তথ্য রিভিউয়ারের দরকার, প্রতিটি লাইন পড়া ছাড়াই।\n\n## উদাহরণ ওয়ার্কফ্লো: এক কমিট, কম অচেনাজাগা\n\nআপনি একটি ছোট বাগ ঠিক করেছেন এবং একই কমিটে কনফিগ টুইক করেছেন। বাগটি `billing/tax.go`-তে এক লাইনের পরিবর্তন; কনফিগ পরিবর্তন `config/staging.yaml`-এ নতুন এন্ডপয়েন্ট পয়েন্ট করছে।\n\nআপনি চালান `git commit -am "Fix tax rounding"`। আপনার Claude Code git hooks দ্রুত একটি সুনির্দিষ্ট আদেশক্রমে কয়েকটি চেক চালায়।\n\nপ্রথমে, সিক্রেট স্ক্যান যা দেখছে কি পরিবর্তন হয়েছে, পুরো রেপো নয়। এটি ফ্ল্যাগ করে যে স্টেজ করা কনফিগে কিছু আছে যা একটি বাস্তব API কী বলে মনে হচ্ছে।\n\n```text
ERROR: Possible secret detected in config/staging.yaml:12
Pattern: api_key=sk_live_...
Fix: remove the key and use an env var reference (e.g., API_KEY)
Override: set ALLOW_SECRETS=1 (not recommended)
```\n\nআপনি সেই মানটি এনভায়রনমেন্ট ভ্যারিয়েবলে বদলান, তারপর আবার কমিট করেন।\n\nএরপর ফর্ম্যাটিং কেবল যেখানে প্রয়োজন সেখানে চলে। আপনার Go ফাইল যদি ফর্ম্যাটেড না থাকে, তখন এটি ছোট একটি হিন্ট দিয়ে ফেল করে যেমন “run gofmt on billing/tax.go”। আপনি ফর্ম্যাটার চালান, এবং হুক সেকেন্ডে পাস করে।\n\nতারপর টেস্ট গেট একটি টার্গেটেড সেট চালায়। যেহেতু আপনি `billing/` টাচ করেছেন, কেবল billing ইউনিট টেস্টগুলো চলে (পূর্ণ সুইট নয়)। যদি কোনো টেস্ট ফেল করে, হুকটি লোকালভাবে পুনরুত্পাদন করার জন্য নির্দিষ্ট কমান্ড দেখায়। আপনি রাউন্ডিং এজ কেস ফিক্স করেন এবং একই টেস্টগুলো পুনরায় চালান।\n\nশেষে, হুক ডিফ থেকে একটি রিভিউয়ার সারাংশ জেনারেট করে। এটি সংক্ষিপ্ত ও নির্দিষ্ট, যেমন:\n\n- What changed: Fix rounding in tax calculation for values ending in .005\n- Config: staging now reads API key from env var\n- Tests: billing unit tests passed\n- Risk: affects billing totals, but limited to tax rounding path\n\nরিভিউয়ার যা দেখে তা হলো একটি পরিষ্কার কমিট: কোনো লিক করা সিক্রেট নেই, ফর্ম্যাটিং কনসিস্টেন্ট, এবং পরিবর্তনের সাথে মিল রেখে টেস্ট চালানো হয়েছে। এদের সাথে একটি প্রস্তুত সারাংশও আছে, তাই তারা লজিকই দেখবেন, প্রতি লাইন খোঁজাখুঁজি নয়।\n\n## সাধারণ ভুল ও কিভাবে আটকাবেন\n\nহুকগুলোকে ব্যর্থ করানোর দ্রুততম উপায় হলো সেগুলো কষ্টকর করে তোলা। যদি একটি হুক আপনার ফ্লো নষ্ট করার মত ধীর হয়, মানুষ `--no-verify` দিয়ে বাইপাস করবে বা হুক মুছে ফেলবে। যেকোনো ভারী কাজ `pre-commit` থেকে দূরে রাখুন ও CI বা অন-ডিমান্ড রাখুন।\n\nএকটি ব্যবহারিক নিয়ম: `pre-commit` টাইপোগ্রাফি চেকের মতো মনে হওয়া উচিত, টেস্ট সুইটের মতো না। যদি আপনি Claude Code থেকে স্মার্ট চেক চান, সেগুলোকে বলে দিন কি চালাতে হবে, সবকিছু চালাতে বলবেন না।\n\n### 1) খুব ধীর হুক\n\nডিফল্টভাবে দ্রুত রাখুন এবং যখন প্রয়োজন কঠোর রাখুন। উদাহরণ: প্রতিটি কমিটে দ্রুত ফর্ম্যাট + সিক্রেট স্ক্যান চালান, কিন্তু টেস্টগুলো কেবল প্রভাবিত মডিউলগুলোর জন্য চালান।\n\nএকটি সহজ গতি বাজেট যা ভাল কাজ করে:

- `pre-commit`: মোট 1 থেকে 5 সেকেন্ড
- `commit-msg`: 1 সেকেন্ডের কম
- যা কিছু বেশি: pre-push বা CI-তে সরান\n\n### 2) AI আউটপুট ছাড়া নির্দিষ্ট নিয়ম না থাকা\n\nAI সুপারিশে মহান, নীতিতে নয়। যদি আপনি AI-কে কেবল “ডিফ রিভিউ কর” বলেন বিনা নিয়মে, আপনি প্রতিবার ভিন্ন ফল পাবেন। হুককে কি করতে হবে (এবং কি কখনো করা যাবে না) তা সংজ্ঞায়িত করুন। উদাহরণ: এটি রিভিউয়ার সারাংশ তৈরি করতে পারে, কিন্তু কোড নিজে পুনরায় লেখার অনুমতি পাবে না যদি না ফর্ম্যাটার deterministic পরিবর্তন করেছে।\n\n### 3) স্টেজড বনাম আনস্টেজড বিভ্রান্তি\n\nঅনেক হুক ভুলভাবে আপনার ওয়ার্কিং ট্রি স্ক্যান করে, তারপর আপনি কমিট করলে ফেল করে কারণ আপনি সব কিছু স্টেজ করেননি—এটা অনুচিত মনে হয়।\n\nসমাধান: সব সময় স্টেজ করা কনটেন্টকে ইনপুট হিসেবে ব্যবহার করুন। একটি ভালো পরীক্ষা: একটি ফাইল এডিট করে সেটা আংশিক স্টেজ করুন এবং দেখুন হুক কেবল স্টেজ করা অংশই রিপোর্ট করে কিনা।\n\n### 4) অতিরিক্ত ফলস পজিটিভ\n\nপ্রতিটি কমিট যদি সতর্কবার্তা দেয়, সতর্কবার্তাগুলো শব্দ হয়ে যায়। প্যাটার্নগুলো টিউন করুন, পরিচিত নিরাপদ স্ট্রিংয়ের জন্য allowlist যোগ করুন, এবং “হয়ত” খোঁজগুলোকে ওয়ার্নে নামিয়ে দিন এবং একটি স্পষ্ট ফিক্স দিন।\n\nকনক্রিট উদাহরণ: আপনার সিক্রেট স্ক্যানার যদি `fixtures/`-এ টেস্ট কী ফ্ল্যাগ করে, ঐ ফোল্ডারটি ইগনোর করুন, কিন্তু অ্যাপ কনফিগ ফাইলগুলোর রিয়েল কী ব্লক করা চালিয়ে রাখুন।\n\n## দ্রুত চেকলিস্ট ও পরবর্তী ধাপগুলো\n\nClaude Code git hooks টিমকে বিরক্ত না করে সাহায্য করতে চাইলে লক্ষ্য সরল: বাস্তব সমস্যাগুলো শুরুতেই ধরুন, সব কিছু সাধারন হলে চুপ থাকুন, এবং কমিট লুপ দ্রুত রাখুন।\n\nএকটি ব্যবহারিক চেকলিস্ট যা বেশিরভাগ রেপোতে কাজ করে:

- অধিকাংশ পরিবর্তনের জন্য pre-commit কয়েক সেকেন্ডের মধ্যে রাখুন। ধীর হলে মানুষ বাইপাস করবে।
- কেবল স্টেজ করা ফাইল স্ক্যান, ফর্ম্যাট, ও লিন্ট করুন। অন্য সবকিছু pre-push বা CI-তে রাখা উচিত।
- স্পষ্ট সিক্রেটস ব্লক করুন (API কী, প্রাইভেট কী, টোকেন)। “হয়ত” কেসে সতর্কবার্তা এবং ডেভেলপার কনফার্ম করার সুযোগ দিন।
- টাচ করা মডিউলগুলোর জন্য টার্গেটেড টেস্ট বাধ্যত করুন কমিটে, তারপর পুশ/CI-তে বিস্তৃত টেস্ট চালান।
- একটি সংক্ষিপ্ত, কনসিস্টেন্ট কমিট সারাংশ যোগ করুন যাতে রিভিউয়ার জানে কি পরিবর্তিত হয়েছে ও কি দেখবে।\n\nএকটি ছোট বিশদ যা কাজে আসবে: রিভিউয়ার সারাংশ প্রতিবার একই রকম রাখুন। একটি সরল টেমপ্লেটই যথেষ্ট, এবং এটি রিভিউয়ারদের দ্রুত স্ক্যান করা শেখায়।\n\n```text
Review summary:
- What changed: <1-2 bullets>
- Risky areas: <files/modules>
- Tests run: <command or “not run + why”>
```\n\nপাঠানোর সহজ পরবর্তী ধাপগুলো:

- প্রথমে একটি স্যান্ডবক্স প্রজেক্টে ফ্লো প্রোটোটাইপ করুন, তারপর যখন ঠিক লাগবে সেটি রিয়েল রেপোতে কপি করুন।
- প্রথমে “warn only” মোডে এক সপ্তাহ চালান, ফলস পজিটিভ মাপুন, তারপর সবচেয়ে নির্ভরযোগ্য চেকগুলো “block” করুন।
- জরুরি ক্ষেত্রে হুক স্কিপ করার জন্য একটি স্পষ্ট escape hatch দিন (উদাহরণ: কমিট মেসেজে কারণ লিখে স্কিপ), এবং কখন এটা হয় তা লগ করুন।
- পূর্ণ টেস্ট সুইট, গভীর সিক্রেট স্ক্যান, ডিপেন্ডেন্সি অডিট—এসব ধীর কাজ pre-push বা CI-তে সরান যাতে কমিট দ্রুত থাকে।\n\nযদি আপনি চ্যাট-ফার্স্ট উপায়ে টুলিং তৈরি করতে চান, Koder.ai (koder.ai) হুক-ঘুরে ছোট হেল্পার স্ক্রিপ্টগুলো জেনারেট করতে ও নিরাপদে ইটারেট করতে সহায়ক হতে পারে, তারপর আপনি সোর্স কোড রেপোতে এক্সপোর্ট করবেন।