Git hooks ของ Claude Code เพื่อการคอมมิตที่ปลอดภัยและการรีวิวที่รวดเร็วขึ้น

Q: What are the best checks to run at commit time?

Start with the repeat offenders that waste reviewer time: - Secret scanning on staged changes - Formatting only for staged files - Fast lint (or type check) for touched files - A short reviewer summary generated from the diff Keep anything slow (full test suite, deep static analysis) for or CI.

Q: Which git hook should I use for what—pre-commit, commit-msg, or pre-push?

A good default is: - for fast checks that look at staged changes (secrets, formatting, quick lint, selective unit tests) - for commit message rules (length, format, ticket ID) - for slower but still local checks (broader tests, builds) If a check regularly takes more than a few seconds, move it later.

Q: How do I scan for secrets without making commits slow?

Scan the staged diff (the index), not the whole repo. - It’s faster. - It’s fairer (it flags what you’re about to commit, not old files). - It reduces noise from unrelated history. If you need a full-repo scan, run it on a schedule or in CI.

Q: How do I keep hooks from becoming flaky or slowing down commits?

Make hooks predictable and fast: - Set a time budget (e.g., 1–5 seconds for ) - Add clear error messages: file, line, and one fix command - Decide a failure policy for timeouts (block, warn, or fallback) - Log “skips” sparingly so people don’t hide bypasses If the hook feels flaky or slow, developers will reach for .

เข้าสู่ระบบ เริ่มต้นใช้งาน

ทำไมการอัตโนมัติขณะคอมมิตจึงสำคัญ

ความเจ็บปวดในการรีวิวส่วนใหญ่ไม่มาจากโค้ดยาก ๆ แต่เกิดจากความผิดพลาดที่เลี่ยงได้ซึ่งหลุดเข้ามาในคอมมิต: เปิด debug flag ทิ้งไว้ ไฟล์ที่ไม่ฟอร์แมตซึ่งสร้าง diff ดังเกินจำเป็น เทสต์ที่ไม่ได้อัปเดต หรือความลับที่ไปโผล่ในคอนฟิก แต่ละอย่างอาจเล็กน้อย แต่รวมกันแล้วทำให้รีวิวสะดุดเป็นการถามตอบยืดเยื้อ

การอัตโนมัติขณะคอมมิตเป็นจุดที่ง่ายสุดในการหยุดปัญหาเหล่านี้ เมื่อตรวจสอบทำงานทันทีตรงก่อนสร้างคอมมิต มันจะจับปัญหาได้ตอนที่การเปลี่ยนแปลงยังสดในหัวคุณ การแก้ไขใช้เวลาเป็นวินาทีเพราะคุณยังอยู่ในบริบทเดียวกัน เทียบกับการเจอปัญหาหลังจากสองวันใน pull request ที่มีคอมมิตเพิ่มขึ้นอีกและผู้ตรวจต้องมาตามถามว่าเกิดอะไรขึ้น

Git hooks เป็นเครื่องมือที่ใช้งานได้จริงเพราะรันได้แบบโลคัล โดยไม่ต้องรอ CI แต่ก็ไม่ใช่เวทมนตร์ Hooks อาจถูกข้าม ถูกคอนฟิกผิด หรือไม่เหมือนกันในแต่ละเครื่องถ้าทีมไม่มาตรฐาน และพวกมันก็ไม่สามารถรับประกันคุณภาพด้วยตัวเอง คิดว่ามันเป็นราวกันตก ไม่ใช่ประตูปิดกั้น

จุดที่ hooks ช่วยได้มากคือการป้องกัน “ภาษีการรีวิว” ข้อเสนอแนะซ้ำ ๆ ที่มีมูลค่าน้อยแต่เกิดขึ้นบ่อย ตัวอย่างปกติได้แก่ strings ที่ดูคล้ายโทเคน การฟอร์แมตและลินต์ที่สร้างเสียงรบกวน การเช็ครันเทสต์พื้นฐานว่าเรียกเทสต์ที่ถูกต้องไหม และสรุปบริบทสั้น ๆ ที่ช่วยให้ผู้ตรวจเข้าใจเจตนา

นี่คือที่ที่ Claude Code git hooks เข้ามา: พวกมันสามารถทำงานตรวจสอบที่น่าเบื่อและเพิ่มบริบทที่อ่านง่ายในจังหวะที่คอมมิตเกิดขึ้นพอดี

การตั้งความคาดหวังสำคัญ ทำให้ hooks โลคัลเร็วและคาดเดาได้เพื่อให้คนไม่เกลียดมัน การตรวจสอบที่ช้าให้ไปไว้ในที่อื่น การแบ่งงานที่ดีคือวินาทีตอนคอมมิต และนาทีใน CI ถ้า hook ใช้เวลานานจนคนต้องเลือกข้าม มันก็หยุดปกป้องรีโปของคุณ

ตัวอย่างง่าย ๆ: คุณเปลี่ยนโมดูลเดียวและรีแฟกเตอร์ฟังก์ชันสองสามตัว ถ้าไม่มีออโตเมชัน ผู้ตรวจเห็นการย้าย 400 บรรทัด ไม่มีการกล่าวถึงเทสต์ และต้องถามคำถามพื้นฐาน แต่ถ้ามีการตรวจขณะคอมมิต คอมมิตจะถูกฟอร์แมต ชุดเทสต์ที่เกี่ยวข้องถูกรัน และข้อความคอมมิตมีสรุปสั้น ๆ การรีวิวเริ่มที่จุดที่ควรเป็น: ที่การออกแบบ ไม่ใช่การทำความสะอาด

Claude Code เพิ่มอะไรให้กับ git hooks

Git hooks ดีสำหรับการเช็คง่าย ๆ แต่โดยทั่วไปมักหยุดที่กฎตอบใช่-ไม่: “ไฟล์ถูกฟอร์แมตไหม?” หรือ “คุณรันลินต์หรือยัง?” Claude Code สามารถเพิ่มชั้นการตัดสินใจเบา ๆ โดยอ่าน diff ที่ถูกสเตจแล้วและไฟล์ที่เกี่ยวข้องไม่กี่ไฟล์ จากนั้นตัดสินใจให้อัตโนมัติใกล้เคียงกับการรีวิวของมนุษย์มากขึ้น

ด้วย Claude Code git hooks, hook สามารถดูสิ่งที่คุณเปลี่ยนจริง ๆ ไม่ใช่แค่สิ่งที่มีอยู่ในรีโป นั่นทำให้ออโตเมชันเลือกทำงานได้เฉพาะจุด มันสามารถมุ่งไปที่โมดูลที่ถูกแตะ ไฟล์คอนฟิกที่แก้ไข และตัวแปรแวดล้อมใหม่ แทนที่จะถือว่าทุกคอมมิตเหมือนการสร้างทั้งหมด

งานเชิงปฏิบัติที่การ “อ่าน diff แล้วคิด” ให้ผลได้แก่:

แจ้งเตือนความลับที่เป็นไปได้ (API keys, tokens, private keys) แม้จะถูกพรางเล็กน้อยหรือแยกบรรทัด
บังคับการฟอร์แมตพร้อมบริบท เช่น รันฟอร์แมตเตอร์เฉพาะไฟล์ที่สเตจไว้และเตือนเมื่อฟอร์แมตเตอร์จะสร้างการเปลี่ยนแปลงใหญ่ที่ไม่เกี่ยวข้อง
แนะนำหรือบังคับเทสต์ตามสิ่งที่เปลี่ยน (เช่น “คุณแตะ logic การชำระเงิน ให้รันเทสต์หน่วยเหล่านี้”) แทนการ “รันทั้งหมด”
สร้างสรุปสั้นสำหรับผู้ตรวจจาก diff: เปลี่ยนอะไร ทำไม จุดเสี่ยง และสิ่งที่ควรตรวจ

ข้อจำกัดสำคัญเพราะ hook ที่ช้าจะกลายเป็น hook ที่ถูกข้าม ตั้งเป้าเล็ก ๆ: เพิ่มราวกันตกที่จับข้อผิดพลาดทั่วไปตั้งแต่ต้น ไม่ใช่ระบบ CI สองที่บนทุกคอมมิต

ความเร็วและความน่าเชื่อถือต้องมาก่อน

กฎที่ดีคือ: ถ้ามันจบงานไม่ได้ในไม่กี่วินาที มันน่าจะไปอยู่ใน CI หรือ pre-push หลายทีมรันเช็คลัดบนเครื่องตอนคอมมิตและทิ้งชุดเทสต์หนักให้ที่หลัง

วางแผนโหมดล้มเหลวไว้ ถ้าการเรียกโมเดลหมดเวลา ให้ตัดสินใจว่าจะบล็อกคอมมิตหรือ fallback ไปใช้การเช็คที่ง่ายกว่า Fallback ทำให้ workflow คาดเดาได้และหลีกเลี่ยงการฝึกคนให้ปิด hooks

ความเป็นส่วนตัว และออนไลน์ vs ออฟไลน์

บางการตั้งค่าจะเรียกโมเดลโฮสต์ บางการตั้งค่ารันในสภาพแวดล้อมแยก ให้ตัดสินใจว่าโค้ดส่วนไหนสามารถออกจากเครื่องนักพัฒนาได้ (ถ้ามี) และจำกัดสิ่งที่จะส่ง สเตจด diff บวกไฟล์อ้างอิงจำนวนน้อยมักพอแล้ว

ถ้าคุณทำงานกับรีโปที่มีความอ่อนไหว ให้ชัดเจนว่าแอนาลิซิสรันที่ไหนและอะไรจะถูกล็อก ตัวอย่างชัดเจน: ถ้าคอมมิตเพิ่มค่า config ใหม่เช่น STRIPE_SECRET=... hook สามารถหยุดคอมมิต อธิบายว่าดูเสี่ยง และแนะนำให้ย้ายไปยัง secret manager หรือไฟล์ env ท้องถิ่นก่อนจะส่งขึ้นรีโมท

เลือก hook ที่เหมาะและทำให้เร็ว

Git hooks มีประโยชน์เฉพาะเมื่อคนเปิดใช้และไม่เริ่มเกลียดการคอมมิต เทคนิคคือเลือก hook ที่เหมาะกับงานและไม่ใส่สิ่งช้าที่สุดลงในเส้นทางร้อน

แผนที่ง่าย ๆ ว่าการตรวจมักจะอยู่ตรงไหน:

pre-commit: การเช็คเร็ว ๆ บนเครื่องที่บล็อกปัญหาชัดเจน (การฟอร์แมต, สแกนความลับ, ลินต์แบบเร็ว)
commit-msg: การเช็คที่ต้องการแค่ข้อความคอมมิต (รหัสบัตร, ความยาว, รูปแบบ)
pre-push: งานหนักกว่าเล็กน้อยที่ยังคุ้มค่าก่อนขึ้นรีโมท (เทสต์ช้ากว่า, การตรวจชนิด, การสร้าง)

เมื่อเพิ่ม Claude Code git hooks ให้ปฏิบัติกับมันเหมือนผู้ตรวจที่ช่วยเหลือและโผล่มาทันที ไม่ใช่คอขวด หากต้องการเรียกเครือข่าย ชุดเทสต์เต็ม หรือการวิเคราะห์ยาว ให้โยกไป pre-push หรือ CI

วิธีปฏิบัติที่เป็นประโยชน์คือจัดเรียงการตรวจตามความเร็วและผลกระทบ ถ้ามันจับปัญหาความเสี่ยงสูง (เช่น กุญแจรั่วไหล) และรันได้ในหนึ่งหรือสองวินาที มันควรอยู่ใน pre-commit ถ้ามันใช้ 30–90 วินาที ให้ย้ายไป pre-push หรือรันเฉพาะเมื่อไฟล์บางอย่างเปลี่ยน

ทีมควรกำหนดท่าทีชัดเจนด้านการบังคับใช้ สำหรับรีโปคนเดียว โหมด opt-in อาจพอได้ สำหรับรีโปทีม มักบังคับพื้นฐาน (ความลับ, ฟอร์แมต, กฎข้อความคอมมิต) และเก็บการตรวจหนักเป็นแนะแนวในเครื่อง ส่วน CI เป็นเกตสุดท้าย

ผลลัพธ์ของ hook สำคัญกว่าที่คิด Hook ที่ล้มเหลวควรบอกว่าเกิดอะไรขึ้นและต้องทำอะไรต่อ ให้ข้อความสั้นและเฉพาะเจาะจง แสดงไฟล์และบรรทัดเมื่อเป็นไปได้ ให้คำสั่งแก้ไขเดียวที่ชัดเจน อธิบายวิธีข้ามเฉพาะสำหรับเหตุฉุกเฉินจริง (และเมื่อไม่ควรทำ) และหลีกเลี่ยงล็อกยาวจนกว่าผู้ใช้จะขอโหมด “verbose”

ตัวอย่าง: ถ้าคุณส่งโปรเจกต์จาก Koder.ai แล้วเริ่มคอมมิตโลคัล pre-commit ที่เร็วสามารถจับโทเคน API ที่คัดลอกมาทันที ในขณะที่ pre-push รันกฎช้ากว่าอย่าง “รันเทสต์เฉพาะโมดูลที่เปลี่ยน” ก่อนใครจะเห็นสาขา

หยุดความลับก่อนจะคอมมิต

ความลับคืออะไรก็ได้ที่ทำให้ใครบางคนแสดงตัวเป็นคุณหรือเข้าถึงระบบส่วนตัว คิดถึง API tokens, OAuth client secrets, cloud keys, รหัสผ่านฐานข้อมูล, URL webhook ส่วนตัว, กุญแจลงนาม และแม้แต่ credential ชั่วคราวในเทสต์ การคอมมิตผิดครั้งเดียวอาจลงไปอยู่ในฟอร์ก, log ของ CI, หรือ diff ที่ถูกวาง แล้วมันจะไม่เป็นชั่วคราวอีกต่อไป

ชัยชนะที่ง่ายที่สุดคือสแกนเฉพาะสิ่งที่คุณกำลังจะคอมมิต Hook ควรตรวจการเปลี่ยนแปลงที่สเตจ (index) ไม่ใช่ทั้งรีโป นั่นทำให้มันเร็วและหลีกเลี่ยงเสียงรบกวนจากไฟล์เก่า ๆ ที่คุณไม่ได้แตะ นอกจากนี้ยังทำให้ฟีดแบ็กยุติธรรม: “คอมมิตนี้มีปัญหา” แทน “รีโปของคุณเคยมีปัญหา”

สิ่งที่ควรแจ้งเตือนโดยทั่วไปได้แก่ token ความเอนโทรปีสูง (สตริงยาวสุ่มดูแปลก), รูปแบบกุญแจที่รู้จัก (AWS keys, GitHub tokens, JWTs), รูปแบบอย่าง password=... หรือ api_key: ... ในคอนฟิก, URL ส่วนตัวที่ฝั่ง credential มา, ไฟล์ .env หรือการคัดลอกคอนฟิกโปรดักชัน

ผลบวกเทียมเกิดขึ้นได้ โดยเฉพาะกับข้อมูลทดสอบ แฮช หรือเอกสารตัวอย่าง ใส่ allowlist แคบ ๆ เพื่อให้คนขยับต่อได้โดยไม่ต้องปิดการเช็คทั้งหมด เก็บ allowlist ให้แคบ: path ของไฟล์ตัวอย่างที่แน่นอนหรือเครื่องหมายชัดเจนเช่น “dummy” หรือ “example” ที่ตัวตรวจรู้ได้

เมื่อพบความลับ ให้ล้มเหลวคอมมิตพร้อมข้อความที่บอกคนว่าต้องทำอะไรต่อ Claude Code git hooks สามารถทำให้เป็นมิตรขึ้นด้วยการสร้างคำอธิบายสั้นจาก 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

ตัวอย่างที่เป็นรูปธรรม: ใครสักคนอัปเดตคอนฟิกแบ็กเอนด์และเพิ่ม TEMP_API_KEY เพื่อให้ฟีเจอร์ใช้ได้ใน dev Hook หยุดคอมมิต แนะนำให้ย้ายไปยังตัวแปรแวดล้อม และเตือนให้หมุนคีย์ถ้ามันเป็นของจริง นี่เป็นการขัดจังหวะเล็ก ๆ ที่ป้องกันงานทำความสะอาดใหญ่ในภายหลัง

บังคับการฟอร์แมตโดยไม่ทำให้คนช้ำใจ

สร้าง hooks ในไม่กี่นาที

สร้างตัวช่วย pre-commit ผ่านแชท แล้วส่งสคริปต์เข้ารีโปของคุณ

ลองฟรี

การทะเลาะเรื่องฟอร์แมตเปลืองเวลาผู้ตรวจ แต่ hook ที่ช้าคือวิธีเร็วที่จะทำให้ hooks ถูกปิด จุดที่ลงตัวคือกฎเรียบง่าย เครื่องมือหนึ่งต่อภาษา และทำเฉพาะไฟล์ที่จะคอมมิต

เลือกฟอร์แมตเตอร์เดียวต่อภาษาและทำให้มันเป็นแหล่งความจริง ฟอร์แมตเตอร์สองตัวที่ขัดแย้งกัน (หรือฟอร์แมตเตอร์กับลินต์ที่เขียนโค้ดใหม่) จะสร้าง diff ดังและวนลูปไม่มีที่สิ้นสุด ทำให้มันน่าเบื่อ: หนึ่งฟอร์แมตเตอร์สำหรับ JS/TS, หนึ่งสำหรับ Go, หนึ่งสำหรับ Dart แล้วให้แน่ใจว่าทุกคนใช้เวอร์ชันเดียวกันเพื่อให้ผลลัพธ์คงที่ข้ามเครื่อง

การเพิ่มความเร็วที่ใหญ่ที่สุดคือฟอร์แมตเฉพาะไฟล์ที่สเตจ การฟอร์แมตรีโปทั้งอันในทุกคอมมิตคือเหตุผลหลักที่ทีมบ่นเกี่ยวกับ pre-commit วิธีสเตจ-เฉพาะยังทำให้ diff โฟกัสที่สิ่งที่คุณเปลี่ยน ซึ่งเป็นสิ่งที่ผู้ตรวจต้องการ

ชุดการเลือกที่เป็นประโยชน์เพื่อให้คอมมิตเร็ว:

รันการฟอร์แมตบนไฟล์ที่สเตจเท่านั้น
ใช้ auto-fix สำหรับการเปลี่ยนแปลงที่ปลอดภัย (การเว้นวรรค, เครื่องหมายคำพูด, ลำดับ import)
ล้มเหลวอย่างเร็วเมื่อจำเป็นต้องตัดสินใจโดยมนุษย์ (เช่น กฎที่อาจเปลี่ยนพฤติกรรม)
เก็บเอาต์พุตฟอร์แมตเตอร์เงียบ ๆ เว้นแต่มีการเปลี่ยนแปลง
แคชเมื่อทำได้ แต่ไม่แลกกับความถูกต้อง

Auto-fix กับล้มเหลวขึ้นอยู่กับความชอบทีม แต่แนวทางผสมทำงานได้ดี Auto-fix ดีสำหรับการแก้ไขเชิงกลไกเพราะหลีกเลี่ยงวงจร “คอมมิต, ล้มเหลว, รันใหม่, คอมมิตอีกครั้ง” การล้มเหลวอาจดีกว่าเมื่อคุณอยากให้คนเห็นปัญหาและเลือกทางออก หากล้มเหลว ให้พิมพ์คำสั่งเดียวที่ใครก็ทำตามได้ใน 10 วินาที

ทำมาตรฐานกับสิ่งเล็ก ๆ ที่ทำให้เกิดเสียงรบกวนข้ามแพลตฟอร์ม newline และช่องว่างท้ายบรรทัดเป็นผู้สร้างปัญหา โดยเฉพาะเมื่อคนสลับระหว่าง Windows, macOS และ CI

นโยบายง่าย ๆ ที่ปวดหัวน้อย:

บังคับใช้ LF line endings ในรีโป
ตัด trailing whitespace บนบรรทัดที่แก้ไข
แน่ใจว่าไฟล์จบด้วย newline
ข้ามการฟอร์แมตสำหรับไฟล์ที่สร้างโดยอัตโนมัติและโฟลเดอร์ vendor

ที่ Claude Code git hooks ช่วยได้คือการเชื่อม: ตรวจว่าไฟล์ที่สเตจต้องใช้ฟอร์แมตเตอร์ตัวไหน, รันมันตามลำดับที่ถูก, และอธิบายความล้มเหลวเป็นภาษาธรรมดา ตัวอย่างเช่น ถ้าใครสเตจไฟล์ Go และไฟล์ TS, hook สามารถฟอร์แมตแต่ละไฟล์ด้วยเครื่องมือที่ถูกต้อง, รีสเตจผลลัพธ์, แล้วพิมพ์โน้ตสั้น ๆ แบบ “2 ไฟล์ถูกฟอร์แมต ไม่มีการเปลี่ยนแปลงพฤติกรรม” ผู้ตรวจเห็น diff ที่สะอาดขึ้น และนักพัฒนาไม่รู้สึกว่าถูกลงโทษสำหรับการคอมมิตบ่อย

บังคับเทสต์สำหรับสิ่งที่คุณเปลี่ยน

กฎง่าย ๆ ทำให้คอมมิตปลอดภัยโดยไม่เจ็บปวด: รันเทสต์เฉพาะเทสต์ที่ตรงกับสิ่งที่คุณสเตจ เมื่อ hook อ่านสเตจด diff (ไม่ใช่ working tree) มันหลีกเลี่ยงการแจ้งเตือนเท็จจากไฟล์ที่แก้ไม่เสร็จ

เริ่มจากการตรวจว่าพื้นที่ไหนถูกรบกวน รีโปส่วนใหญ่มีโครงสร้างธรรมชาติ: packages, services, apps หรือ modules Hook สามารถอ่าน git diff --cached --name-only แล้วแม็ปพาธเหล่านั้นไปยังชุดคำสั่งเทสต์ขนาดเล็ก

นี่คือกฎแม็ปที่คงไว้ซึ่งความเข้าใจได้เมื่อกลับมาดู:

web/ หรือ frontend/ -> รัน npm test (หรือคำสั่งเป้าหมายที่เล็กที่สุดที่คุณมี)
api/ หรือ server/ -> รัน unit tests ของแบ็กเอนด์ (ข้าม integration ตามค่าเริ่มต้น)
mobile/ -> รันเทสต์ widget/unit ที่เร็ว ไม่ใช่ device suites เต็ม
db/ หรือ migrations/ -> รัน migration linting และเช็กสคีมาขนาดเล็ก
shared/ -> รันเทสต์ของ shared package บวก consumer ที่เร็ว

ถ้าใช้ Claude Code git hooks คุณสามารถก้าวไปอีกขั้น: ให้ Claude ดูชื่อไฟล์ที่สเตจแล้วเสนอชุดเทสต์ขั้นต่ำ จากนั้น hook รันคำสั่งเหล่านั้น แต่ให้กฎสุดท้ายเป็นแบบ rule-based เพื่อให้ทีมคาดเดาได้ว่าจะเกิดอะไรขึ้น

แยกงานระหว่าง commit และ push คอมมิตควรเร็วเพื่อคนจะไม่ข้าม hooks แบบประโยค รูปแบบปฏิบัติได้คือ:

ตอนคอมมิต: รันชุดเร็วที่เลือกได้ (ลินต์ + unit tests สำหรับโมดูลที่แตะ)
ตอนพุช: รันชุดกว้างขึ้น (integration, smoke e2e, เทสต์ข้ามโมดูล)
ใน CI: รันชุดเต็มและบังคับเกตความครอบคลุม

เทสต์ที่คงที่และช้าอยากให้มียุทธศาสตร์ชัดเจน มิฉะนั้น hook จะกลายเป็นเสียงรบกวน ตกลงกันเป็นทีมว่าอะไรบล็อกคอมมิตและอะไรเตือน ทางปฏิบัติได้คือบล็อกเมื่อเกิดความล้มเหลวชัดเจน (ฟอร์แมต, unit tests ที่ปกติไม่ค่อยพัง), เตือนสำหรับเทสต์ flaky และย้ายชุดช้าไปไว้ที่ push/CI ถ้าเทสต์ flaky ให้ถือเป็นบั๊ก: ติดตาม แก้ไข แล้วเอาโหมดเตือนออกเมื่อมันเสถียร

สร้างสรุปสั้นสำหรับผู้ตรวจขณะคอมมิต

ส่งมอบด้วยความมั่นใจ

เมื่อพร้อม ให้ deploy และโฮสต์แอปที่คุณสร้าง แล้วเก็บ hooks ไว้ในรีโปของคุณ

ปรับใช้

diff ที่ดีไม่ได้อ่านง่ายเสมอไป สรุปสั้นขณะคอมมิตช่วยเปลี่ยนการอ่าน 10 นาทีให้เหลือ 2 นาที โดยเฉพาะเมื่อการเปลี่ยนแปลงเกี่ยวหลายไฟล์หรือมีรีแฟกเตอร์

ไอเดียง่าย ๆ คือ: เมื่อคุณรัน git commit hook ของคุณขอให้ Claude Code อ่านสเตจด diff แล้วสร้างโน้ต 3–6 บรรทัดที่ตอบคำถามที่ผู้ตรวจมักมี: เปลี่ยนอะไร ทำไม มีความเสี่ยงแค่ไหน และทดสอบอย่างไร

เทมเพลตสรุปง่าย ๆ

เก็บเอาต์พุตให้กระชับและสม่ำเสมอเพื่อให้ผู้ตรวจเชื่อถือ:

What: ประโยคเดียวเกี่ยวกับการเปลี่ยนแปลงหลัก (ไม่ใช่รายการไฟล์)
Why: ปัญหาผู้ใช้หรือบั๊กที่แก้
Risk: ต่ำ กลาง หรือสูง พร้อมเหตุผลสั้น ๆ
Testing: สิ่งที่คุณรัน (หรือบอกว่า “ไม่ได้รัน”)
Notes: migrations, flags, ขั้นตอน rollout หรือสิ่งที่สำคัญต่อการรีวิว

คุณสามารถใส่ลงในข้อความคอมมิตโดยตรง (เช่น เป็น footer สั้น ๆ) หรือบันทึกเป็นไฟล์ที่ทีมคัดลงในคำอธิบาย PR ข้อความคอมมิตเหมาะเมื่ออยากให้บริบทเดินทางไปกับการเปลี่ยนแปลง ไฟล์แยกเหมาะเมื่อทีมชอบหัวเรื่องคอนเวนชัน

ห้ามรั่วความลับในสรุป

เครื่องมือสรุปควรเข้มงวดกว่ามนุษย์ ก่อนส่งเนื้อหา diff ให้โมเดล ให้กรองบรรทัดที่ตรงกับแพทเทิร์นอย่าง API keys, private keys, tokens, ค่า .env และ credential นอกจากนี้กรอง header และ cookies ถ้ารีโปมีการเก็บทราฟฟิก HTTP ตัว hook เมื่อพบแพทเทิร์นอ่อนไหว สามารถมาร์กออกบรรทัดหรือ fallback เป็นสรุปทั่วไป เช่น “credentials-related changes redacted”

ตัวอย่าง: คุณอัปเดต endpoint การเรียกเก็บเงินและแตะสามไฟล์ Diff สเตจเสียงดังเพราะมีการเปลี่ยนชื่อ แต่สรุปบอกว่า: “เพิ่มการจัดการ idempotency key สำหรับการสร้าง charge เพื่อป้องกันการเรียกเก็บซ้ำ เหตุผล: การ retry ทำให้เกิดการเรียกเก็บซ้ำ ความเสี่ยง: กลาง (เส้นทางการจ่ายเงิน). การทดสอบ: unit tests สำหรับ billing service, manual request replay.” นั่นคือสิ่งที่ผู้ตรวจต้องการ โดยไม่ต้องอ่านทุกบรรทัดก่อน

ตัวอย่างเวิร์กโฟลว์: หนึ่งคอมมิต น้อยการเซอร์ไพรส์

คุณแก้บั๊กเล็ก ๆ และแตะคอนฟิกในคอมมิตเดียว บั๊กคือการเปลี่ยนบรรทัดเดียวใน billing/tax.go คอนฟิกอัปเดต config/staging.yaml ชี้ไปยัง endpoint ใหม่

คุณรัน git commit -am "Fix tax rounding". Claude Code git hooks ทำงานและรันการตรวจเร็ว ๆ เป็นลำดับที่คาดเดาได้

แรกสุด สแกนความลับดูเฉพาะสิ่งที่เปลี่ยน ไม่ใช่ทั้งรีโป มันแจ้งว่า config สเตจมีสิ่งที่ดูเหมือน API key

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)

คุณแทนค่านั้นด้วยการอ้างถึงตัวแปรแวดล้อม แล้วคอมมิตอีกครั้ง

ต่อมา ฟอร์แมตทำงานเฉพาะที่จำเป็น ถ้าไฟล์ Go ของคุณไม่ฟอร์แมต มันจะแสดงคำแนะนำสั้น ๆ เช่น “run gofmt on billing/tax.go” คุณรันฟอร์แมตเตอร์ แล้ว hook ผ่านภายในวินาที

จากนั้นเกตเทสต์รันชุดเป้าหมาย เพราะคุณแตะ billing/ มันรันเฉพาะ billing unit tests (ไม่ใช่ชุดเต็ม) ถ้าเทสต์ตัวนึงล้ม hook แสดงคำสั่งที่ต้องรันซ้ำให้ชัด คุณแก้กรณีขอบและรันเทสต์เดิมอีกครั้ง

สุดท้าย hook สร้างสรุปผู้ตรวจจาก diff สั้นและเฉพาะเจาะจง เช่น:

What changed: Fix rounding in tax calculation for values ending in .005
Config: staging now reads API key from env var
Tests: billing unit tests passed
Risk: affects billing totals, but limited to tax rounding path

สิ่งที่ผู้ตรวจเห็นคือคอมมิตที่สะอาดอยู่แล้ว: ไม่มีความลับรั่ว ฟอร์แมตสอดคล้อง เทสต์ที่สอดคล้องกับการเปลี่ยนแปลง และมีสรุปพร้อมสำหรับการรีวิว ผู้ตรวจจึงโฟกัสที่ตรรกะแทนการค้นหาเจตนา

ความผิดพลาดทั่วไปและวิธีหลีกเลี่ยง

วางแผนเวิร์กโฟลว์ของคุณ

ใช้โหมดวางแผนเพื่อแม็ปการตรวจสอบไปยัง pre-commit, commit-msg และ pre-push

เริ่มวางแผน

ทางที่เร็วที่สุดที่จะทำให้ hooks ล้มคือตั้งให้มันเจ็บปวด ถ้า hook ใช้เวลานานพอจะขัดจังหวะการทำงาน คนจะข้ามมันด้วย --no-verify หรือลบทิ้ง ให้อะไรหนัก ๆ ออกจาก pre-commit และรันใน CI หรือเมื่อขอ

กฎปฏิบัติ: pre-commit ควรรู้สึกเหมือนการตรวจการพิมพ์ ไม่ใช่ชุดเทสต์ หากต้องการเช็คที่ฉลาดขึ้นจาก Claude Code git hooks ให้ใช้มันเพื่อตัดสินใจว่าจะรันอะไร ไม่ใช่รันทุกอย่าง

1) Hooks ที่ช้าจนเกินไป

ทำให้ hooks เร็วตามค่าเริ่มต้นและเข้มงวดเฉพาะเมื่อจำเป็น เช่น รันฟอร์แมตเร็ว + สแกนความลับในทุกคอมมิต แต่รันเทสต์เฉพาะโมดูลที่เกี่ยวข้อง

งบเวลาที่ใช้ได้ดี:

pre-commit: รวม 1 ถึง 5 วินาที
commit-msg: ต่ำกว่า 1 วินาที
อะไรที่นานกว่านี้: ย้ายไป pre-push หรือ CI

2) เอาต์พุต AI ที่ไม่มีกรอบชัดเจน

AI เก่งที่การแนะนำ ไม่ใช่นโยบาย ถ้าคุณถาม AI ให้ “รีวิว diff” โดยไม่มีกรอบ คุณจะได้ผลไม่สม่ำเสมอ กำหนดสิ่งที่ hook ต้องทำ (และสิ่งที่ห้ามทำ) เช่น: มันสามารถสร้างสรุปผู้ตรวจได้ แต่ห้ามเขียนโค้ดใหม่เว้นแต่ฟอร์แมตเตอร์จะทำการเปลี่ยนแปลงที่กำหนดได้

3) สับสนระหว่าง staged กับ unstaged

หลาย hook บังเอิญสแกน working tree แล้วล้มคอมมิตเพราะมีการเปลี่ยนที่คุณยังไม่ได้สเตจ นั่นรู้สึกไม่ยุติธรรม

หลีกเลี่ยงโดยใช้สเตจดเป็นอินพุตเสมอ การทดสอบที่ดี: แก้ไฟล์ สเตจแค่ครึ่ง แล้วยืนยันว่า hook รายงานเฉพาะสิ่งที่สเตจ

4) ผลบวกลวงมากเกินไป

ถ้าทุกคอมมิตทริกเกอร์เตือน เสียงเตือนจะกลายเป็นเสียงรบกวน ปรับแพทเทิร์น ใส่ allowlists สำหรับสตริงที่ปลอดภัยที่รู้จัก และลดระดับการแจ้งเตือนสำหรับผลการจับที่ไม่แน่นอนเป็นเตือนพร้อมคำแก้ไขชัดเจน

ตัวอย่างเป็นรูปธรรม: ถ้าเครื่องสแกนความลับชี้คีย์เทสต์ใน fixtures/ ให้เพิ่มกฎละเว้นโฟลเดอร์นั้น แต่ยังบล็อกคีย์จริงในไฟล์คอนฟิกแอป

เช็คลิสต์ด่วน และขั้นตอนถัดไป

ถ้าคุณอยากให้ Claude Code git hooks ช่วยโดยไม่ทำให้ทีมรำคาญ เป้าหมายคือ: จับปัญหาจริงตั้งแต่ต้น เงียบเมื่อทุกอย่างปกติ และทำให้ลูปการคอมมิตเร็ว

เช็คลิสต์ปฏิบัติที่ใช้ได้กับรีโปส่วนใหญ่:

ทำให้ pre-commit ต่ำกว่าสองสามวินาทีสำหรับการเปลี่ยนแปลงส่วนใหญ่ ถ้ามันช้า คนจะข้ามมัน
สแกน ฟอร์แมต และลินต์เฉพาะไฟล์ที่สเตจ อันอื่นไว้ที่ pre-push หรือ CI
บล็อกความลับชัดเจน (API keys, private keys, tokens). สำหรับกรณี “อาจจะใช่” ให้เตือนและให้ผู้พัฒนายืนยัน
บังคับเทสต์แบบเป้าหมายตอนคอมมิตสำหรับโมดูลที่แตะ แล้วรันเทสต์กว้างบน push หรือ CI
เพิ่มสรุปคอมมิตสั้นและสม่ำเสมอเพื่อให้ผู้ตรวจรู้ว่าต้องโฟกัสตรงไหน

รายละเอียดเล็ก ๆ ที่ให้ผล: ทำให้สรุปผู้ตรวจเหมือนเดิมทุกครั้ง เทมเพลตง่าย ๆ ก็พอ และช่วยให้ผู้ตรวจสแกนได้เร็ว

Review summary:
- What changed: <1-2 bullets>
- Risky areas: <files/modules>
- Tests run: <command or “not run + why”>

ขั้นตอนถัดไปที่ทำให้การนำไปใช้ง่ายขึ้น:

ทดลองเวิร์กโฟลว์ในโปรเจกต์ซานด์บอกซ์ก่อน แล้วคัดลอกเข้ารีโปจริงเมื่อมันลงตัว
เริ่มจากโหมด “เตือนเท่านั้น” เป็นสัปดาห์ วัดผล false positives แล้วสลับการเช็คที่น่าเชื่อถือที่สุดเป็น “บล็อก”
เพิ่มทางออกฉุกเฉิน (เช่น อนุญาตข้าม hook พร้อมเหตุผลชัดเจนในข้อความคอมมิต) และล็อกเมื่อมันเกิดขึ้น
ย้ายสิ่งหนัก (ชุดเทสต์เต็ม, การสแกนความลับเชิงลึก, ตรวจสอบ dependency) ไปที่ pre-push หรือ CI เพื่อให้คอมมิตเร็ว

ถ้าคุณชอบสร้างเครื่องมือแบบ chat-first, Koder.ai (koder.ai) อาจช่วยในการสร้างสคริปต์ตัวช่วยรอบ ๆ hooks และทำซ้ำอย่างปลอดภัยด้วยสแน็ปชอตและย้อนกลับก่อนส่งซอร์สโค้ดเข้ารีโป

คำถามที่พบบ่อย

What are the best checks to run at commit time?

Start with the repeat offenders that waste reviewer time:

Secret scanning on staged changes
Formatting only for staged files
Fast lint (or type check) for touched files
A short reviewer summary generated from the diff

Keep anything slow (full test suite, deep static analysis) for pre-push or CI.

Which git hook should I use for what—pre-commit, commit-msg, or pre-push?

A good default is:

pre-commit for fast checks that look at staged changes (secrets, formatting, quick lint, selective unit tests)
commit-msg for commit message rules (length, format, ticket ID)
pre-push for slower but still local checks (broader tests, builds)

If a check regularly takes more than a few seconds, move it later.

If hooks can be skipped, are they still worth it?

Treat commit-time hooks as guardrails, not your only enforcement.

Use local hooks to catch mistakes early and reduce review noise.
Still enforce the real “must pass” rules in CI, because hooks can be skipped or misconfigured.

A practical policy is: hooks help developers; CI protects the main branch.

How do I scan for secrets without making commits slow?

Scan the staged diff (the index), not the whole repo.

It’s faster.
It’s fairer (it flags what you’re about to commit, not old files).
It reduces noise from unrelated history.

If you need a full-repo scan, run it on a schedule or in CI.

What should I do about false positives from secret detection?

Block when the match is high-confidence (real key formats, private key blocks, obvious password= values in config). Warn when it’s ambiguous.

Also add a narrow allowlist for known safe cases, such as:

Specific fixture paths
Clearly marked example strings (e.g., DUMMY_KEY)

If people see constant false alarms, they’ll disable the hook.

How can I enforce formatting without annoying the team?

Format only staged files, and use one formatter per language.

Practical defaults:

Auto-fix safe formatting changes, then re-stage
Fail with one clear command when a human decision is needed
Skip generated/vendor directories

This keeps diffs clean without turning every commit into a long rewrite.

How do I “require tests for what changed” without running everything?

Map touched paths to a small set of fast test commands.

Example approach:

Detect changed areas via git diff --cached --name-only
Run only the unit tests for those modules
Leave integration/e2e for pre-push or CI

This keeps commits quick while still catching the most common breakages early.

What should a commit-time reviewer summary include?

Keep it short and consistent (3–6 lines). A simple template:

What changed
Why
Risk (low/medium/high + one reason)
Testing (what you ran, or “not run”)

You can append it to the commit message or save it as text output for the PR description.

How do I avoid leaking sensitive code or secrets when using AI in hooks?

Redact before sending anything to a model, and be conservative.

Strip lines that look like tokens, secrets, .env values, private keys, cookies, or auth headers
If sensitive patterns are present, fall back to a generic summary (e.g., “credentials-related lines redacted”)
Send only the staged diff plus minimal referenced context

Default to “share less,” especially in private repos.

How do I keep hooks from becoming flaky or slowing down commits?

Make hooks predictable and fast:

Set a time budget (e.g., 1–5 seconds for pre-commit)
Add clear error messages: file, line, and one fix command
Decide a failure policy for timeouts (block, warn, or fallback)
Log “skips” sparingly so people don’t hide bypasses

If the hook feels flaky or slow, developers will reach for --no-verify.

Git hooks ของ Claude Code เพื่อการคอมมิตที่ปลอดภัยและการรีวิวที่รวดเร็วขึ้น | Koder.ai