Git Blame vs Git Log: วิธีหาคนที่ทำให้ Code พังโดยไม่ Blame กัน

เมื่อเจอ Bug หรือปัญหาที่แปลกประหลาดในโปรแกรม หลายคนที่ทำงานด้วย Git มักจะต้องหา Bug แต่ปัญหาคือ การหา Bug มักเกี่ยวข้องกับการหาว่าใคร ทำให้เกิดปัญหา บ่อยครั้งนี้ทำให้เกิดความตึงเครียด บทความนี้จะอธิบายวิธีการหาว่าใครทำให้ Code ผิดพลาด ด้วยวิธีที่ Constructive (เชิงสร้างสรรค์) และเน้นสำคัญในการทำงานเป็นทีมอย่างสมบูรณ์ โดยเฉพาะเมื่อรันบน ผู้ให้บริการโฮสติ้ง Cloud VPS

ความแตกต่างของ Git Blame และ Git Log

Git Blame และ Git Log เป็นคำสั่งที่ทำงานได้คล้ายกัน แต่ใช้วิธีการที่ต่างกัน:

• Git Blame: ใช้หา Code ไหนเกิดปัญหา ผู้เขียน และเวลาที่เพิ่มเข้ามา โดยตรวจสอบทีละบรรทัด
• Git Log: ใช้เพื่อดูประวัติการ Commit ทั้งหมด สามารถหา Feature หรือ Branch ไหน และทำเมื่อไหร่

ขั้นที่ 1: ตรวจหาบรรทัดที่มีปัญหา

ใช้คำสั่ง git blame เพื่อหา Commit Hash ชื่อ Author และวันเวลาที่ Code นั้นถูกเพิ่มเข้ามา:

git blame filename.js

ขั้นที่ 2: ดูข้อมูล Commit ที่กล่าวมา

# ดูข้อมูล Commit เพื่อเข้าใจความเปลี่ยนแปลง
git show a1b2c3d

ขั้นที่ 3: ศึกษา Context และประวัติการเปลี่ยนแปลง

# ดู Commit History ของไฟล์ที่มีปัญหา
git log -p filename.js

# ดู Author และลำดับ Commit โดยย้อนกลับ
git log -p --reverse filename.js

ขั้นที่ 4: ติดต่อ Author แบบสร้างสรรค์

# ติดต่อ Author เพื่อถามเหตุผล
# ไม่ใช่เพื่อตำหนิ แต่เพื่อเข้าใจความตั้งใจ
Slack/Email: "Hi [Author], I found a bug related to your change in [filename]. 
Can you help me understand why this approach was used?"

ตัวอย่างการใช้ Git Blame

cd /path/to/your/repo
git blame src/app.js | grep -A 5 -B 5 "buggy line"

# Output จะแสดง:
# a1b2c3d (John Developer 2024-03-15 12:34:56 +0700) 123) let x = null;
# a1b2c3d (John Developer 2024-03-15 12:34:56 +0700) 124) if (!x) { ... }

# ดูรายละเอียด Commit a1b2c3d
git show a1b2c3d

การเปรียบเทียบ: Git Blame vs Git Log

ลักษณะ	Git Blame	Git Log
ชนิดข้อมูล	แสดงทีละบรรทัด (Line-by-line)	แสดงทั้งหมด (All commits)
ค้นหา “ใคร?”	ระบุคนโดยตรง	แสดง Author ของทุก Commit
ค้นหา “เมื่อไหร่?”	จากข้อมูล Commit	จากข้อมูล Commit Message
ใช้เมื่อ	หา Bug ในบรรทัดเฉพาะ	ดูประวัติการเปลี่ยนแปลงทั้งหมด

Advanced: ใช้ Git Bisect หาจุดเกิด Bug

หากไม่แน่ใจว่า Commit ไหนเกิด Bug ให้ใช้ Git Bisect เพื่อค้นหาแบบ Binary Search:

# เริ่ม Bisect
git bisect start

# บอก Commit ปัจจุบัน (ที่มี Bug)
git bisect bad HEAD

# บอก Commit เก่า (ที่ไม่มี Bug)
git bisect good v1.0

# Git จะหา Commit กลางทาง และให้คุณตรวจสอบ
# ตรวจสอบว่า Commit นี้มี Bug หรือไม่

git bisect good  # ถ้า Commit นี้ดี (ไม่มี Bug)
git bisect bad   # ถ้า Commit นี้ผิด (มี Bug)

# ทำซ้ำจนกว่า Git หา Commit ที่ทำให้เกิด Bug
# เมื่อเสร็จแล้ว:
git bisect reset

บัญชีการทำงาน: “Blameless Post-Mortem Culture”

เมื่อเจอ Bug ในทีม สิ่งสำคัญคือ “ไม่ใช่การหาคนที่ผิด” แต่เป็นการหาว่า “เกิดอะไรขึ้น” นี่คือสิ่งที่เรียกว่า “Blameless Post-Mortem” ซึ่งเป็นวัฒนธรรมการทำงานที่สำคัญในทีมที่มีประสิทธิภาพ

หลักการ Blameless Post-Mortem

• ไม่หาคนเป็นเป้าหมาย – Bug เกิดจากระบบ ไม่ใช่คนเพียงคนเดียว อาจมาจาก Code Review ที่ไม่ดี หรือการทดสอบที่ไม่เพียงพอ
• ค้นหาเหตุหลัก – Post-Mortem ต้องเป็นการสร้างสรรค์ ไม่ใช่การตำหนิ เน้นไปที่ “เกิดอะไร” ไม่ใช่ “ใครทำให้เกิด”
• กำหนดสิ่งที่ปรับปรุง – หา Root Cause และกำหนดการปรับปรุงเพื่อป้องกันไม่ให้เกิด Bug เดิมอีก

ขั้นตอนการทำ Blameless Post-Mortem

1. เกิด Incident
   - Bug ถูกพบและแจ้งเตือน

2. ตอบสนองทันที (Immediate Response)
   - แจ้งให้ทีมรู้
   - ทำการ Fix หรือ Rollback
   - บันทึกเวลาเหตุการณ์

3. Investigation (ไม่ใช่ Blame)
   - "เกิดอะไร?" (ไม่ใช่ "ใครทำให้เกิด?")
   - ตรวจสอบกระบวนการทำงาน
   - ตรวจสอบ Code Review Process
   - ตรวจสอบ Deployment Checks

4. กำหนด Action Items
   - แก้ไข Bug
   - เพิ่ม Tests เพื่อป้องกัน Regression
   - ปรับปรุง Code Review Process
   - อัปเดต Documentation
   - Training หากจำเป็น

5. แบ่งปันการเรียนรู้
   - เขียน Blameless Post-Mortem Report
   - แบ่งปันกับทีม
   - อัปเดต Runbooks

การเรียนรู้จากความผิดพลาดร่วมกัน

• ใช้ Code Review Process – เพื่อทำการตรวจสอบก่อนที่ Code จะเข้าสู่ Main Branch
• เขียน Unit Tests – เพื่อตรวจสอบ Function โดยละเอียด และป้องกัน Regression
• ใช้ Pair Programming – ทำให้สองคนมองโค้ดพร้อมกัน ลดโอกาสเกิด Bug
• ใช้ Linting และ Formatter – เช่น ESLint, Prettier เพื่อหา Syntax Error และ Code Style อย่างอัตโนมัติ

ตัวอย่างจริง: Bug Hunt ที่สร้างสรรค์

# สถานการณ์: Payment Module มีปัญหา

$ git blame src/payment/processor.js

# หาบรรทัด 42 (ผิดพลาด):
# a1b2c3d4 (Alice Smith 2024-03-10 10:15:00 +0700) 
# 42) process.transaction(amount * 1.1) // คิดธรรมเนียม

$ git show a1b2c3d4

# Commit Message: "Feature: Add automatic fee calculation"
# เข้าใจแล้ว: Alice เพิ่มคุณสมบัติการคิดธรรมเนียมอัตโนมัติ

# ติด Slack:
# "Hi Alice, I found a bug in the fee calculation on line 42. 
#  It looks like we're charging customers 10% extra. 
#  Can we discuss what the original intent was?"

# Alice ตอบ: ความตั้งใจคือให้เก็บ Commission สำหรับ Operator
# แต่ไม่ได้กำหนด Feature Flag เพื่อปิด/เปิด

# Fix:
# 1. สร้าง Feature Flag "AUTO_FEE_ENABLED" (default: false)
# 2. เขียน Unit Test
# 3. อัปเดต Documentation
# 4. สร้าง PR โดยให้ Alice Review

Tools เพื่อป้องกัน Bug

• ESLint / Prettier – ตรวจหา Syntax Error และ Code Style โดยอัตโนมัติ
• Jest / Unit Tests – ทดสอบ Function โดยละเอียด และป้องกัน Regression
• TypeScript – ตรวจหา Type Error ก่อนที่ Code จะถูกรัน
• GitHub Actions / CI/CD – รัน Tests และ Linting อัตโนมัติในทุก Pull Request

สรุป

Git Blame และ Git Log เป็นเครื่องมือที่มีค่ามากในการหา Bug และเข้าใจประวัติ Code วิธีการเหล่านี้ไม่ใช่เพื่อตำหนิใคร แต่เป็นการค้นหา Root Cause ของปัญหา ความสำคัญคือวิธีการใช้ Git Blame ต้องเป็นแบบ Constructive โดยทำให้ทีมเข้าใจ และช่วยเหลือกันแก้ไขปัญหา นี่คือ “Blameless Culture” ที่ทำให้ทีมทำงานได้ดีและมีประสิทธิภาพสูง