รูปปกบทความ

1. 🎯 ตอนที่ 5: การบันทึกประวัติศาสตร์ – ศิลปะของการ Add และ Commit

2. 📖 เปิดฉาก (The Hook)

สวัสดีครับน้องๆ สายโค้ดทุกคน! พี่เชื่อว่าหลายคนน่าจะเคยเจอปัญหาคลาสสิกเวลาต้องกลับไปหาบั๊กในโค้ดเก่า แล้วเปิดประวัติการทำงาน (History) ดูเพื่อหาว่าใครทำพัง… แต่สิ่งที่เจอคือข้อความบันทึกแบบนี้: update -> fix bug -> oops -> change file -> FIRE!!!

อ่านแล้วถึงกับกุมขมับเลยใช่ไหมครับ? ว่าไอ้ “update” เนี่ย มันอัปเดตอะไรไปบ้าง! ในโลกของการทำ Version Control คำสั่งอย่าง git commit ไม่ใช่แค่การกดปุ่ม Save หรือ Checkpoint เซฟเกมให้ผ่านๆ ไป แต่มันคือ “การจดบันทึกประวัติศาสตร์” ที่จะช่วยกู้ชีพเราและทีมงานในอนาคต วันนี้พี่สวมวิญญาณ Senior DevOps จะมาเจาะลึกศิลปะของการใช้คำสั่ง git add และ git commit อย่างมือโปรกันครับ!

3. 🧠 แก่นวิชา (Core Concepts)

คำถามยอดฮิตที่พี่มักจะโดนถามเสมอคือ “ทำไม Git ต้องบังคับให้เราใช้ git add ก่อนที่จะ git commit เสมอ? ทำไมไม่เซฟรวดเดียวไปเลยให้จบๆ ยุ่งยากทำไม?”

คำตอบอยู่ที่ปรัชญาของ Git ครับ Git มีพื้นที่ที่เรียกว่า Staging Area (หรือ Index) ซึ่งทำหน้าที่เป็น “จุดพักคอย” เหตุผลที่ต้องมีจุดนี้คือ Git ต้องการให้เราสร้างสิ่งที่เรียกว่า “Atomic Commit” หรือการบันทึกการเปลี่ยนแปลงเป็นก้อนเล็กๆ ที่มีความหมายสมบูรณ์ในตัวมันเองทีละเรื่อง

ลองจินตนาการว่าใน 1 วันน้องแก้โค้ดไป 10 ไฟล์

  • 5 ไฟล์เป็นการสร้างฟีเจอร์ใหม่
  • อีก 5 ไฟล์เป็นการแก้บั๊กที่บังเอิญเจอ

ถ้าไม่มีคำสั่ง git add น้องจะต้อง Commit ทั้ง 10 ไฟล์รวมกันเป็นก้อนเดียว ประวัติศาสตร์โปรเจกต์จะมั่วมาก แต่ด้วย Staging Area น้องสามารถใช้ git add เลือกเฉพาะ 5 ไฟล์แรกไปตั้งแถวรอ (Stage) แล้วสั่ง git commit เพื่อบันทึกว่าเป็นเรื่อง “ฟีเจอร์ใหม่” จากนั้นค่อยกลับมา git add อีก 5 ไฟล์ที่เหลือ แล้วสั่ง git commit เป็นเรื่อง “แก้บั๊ก” แยกกันได้อย่างสวยงาม!

การทำงานของ Add และ Commit

4. 💻 ร่ายมนต์คำสั่ง (Show me the Commands)

มาดูเวทมนตร์คำสั่งในการหยิบจับไฟล์ใส่กล่องและการถ่ายรูปเก็บ Snapshot กันครับ:

# 1. หยิบไฟล์ที่ต้องการเข้า Staging Area (จัดแถวเตรียมถ่ายรูป)
git add index.html script.js

# 2. ถ้าขี้เกียจพิมพ์ชื่อไฟล์ หยิบทุกไฟล์ที่มีการเปลี่ยนแปลงเข้า Staging Area แบบรวดเดียว! (ใช้ด้วยความระมัดระวังนะ)
git add .

# 3. ถ่ายรูปประวัติศาสตร์! พร้อมแนบป้ายชื่อ (Commit Message)
git commit -m "feat: เพิ่มฟีเจอร์ระบบล็อกอินสำหรับผู้ใช้งาน"

# 4. ท่าลัดฉบับโปร! (Shortcut) ถ้าไฟล์นั้นเคยถูก Track ในระบบ Git อยู่แล้ว 
# สามารถใช้ -am เพื่อสั่ง add และ commit รวบยอดในคำสั่งเดียวได้เลย
git commit -am "fix: แก้ไขบั๊กหน้าจอแสดงผลผิดเพี้ยนในมือถือ"

5. 🛡️ เคล็ดลับจากคัมภีร์ลับ (Under the Hood / Pro-Tips)

ทีนี้มาถึงจุดสำคัญที่สุดครับ นั่นคือ ศิลปะในการเขียน Commit Message จากคู่มือระดับโลก มี Best Practices และกฎเกณฑ์ที่เรียกว่า Conventional Commits ที่โปรแกรมเมอร์มืออาชีพนิยมใช้กันดังนี้ครับ:

  1. โครงสร้างมาตรฐาน: ใช้รูปแบบ <type>: <description>
    • feat: สำหรับฟีเจอร์ใหม่ (Feature)
    • fix: สำหรับแก้บั๊ก (Bug Fix)
    • docs: สำหรับอัปเดตเอกสาร (Documentation)
  2. ใช้ Imperative Mood: ในภาษาอังกฤษ ให้ใช้คำสั่งเชิงออกคำสั่ง เช่น ใช้คำว่า “Fix bug” (จงแก้บั๊ก) แทนที่จะเป็น “Fixed bug” (แก้บั๊กแล้ว) เพื่อให้สอดคล้องกับข้อความอัตโนมัติที่ Git สร้างขึ้น
  3. อธิบาย What และ Why ไม่ใช่ How: ไม่ต้องอธิบายว่าโค้ดบรรทัดไหนแก้อย่างไร (เพราะเราดูจากไฟล์ Diff ได้) แต่ให้อธิบายว่า “ทำอะไร” และ “ทำไปทำไม”

💥 เปรียบเทียบ Commit Message (Good vs. Bad) 💥

❌ แบบที่แย่ (Bad Commits):

  • git commit -m "changed file" (เปลี่ยนอะไรล่ะ?)
  • git commit -m "sync" (ซิงก์ทำไม ไม่รู้เรื่อง!)
  • git commit -m "FIRE" (อ้างอิงจาก Source กฎเหล็กบอกว่าถึงไฟไหม้ออฟฟิศ ก็อย่าเขียนแค่ FIRE ให้เขียนให้รู้เรื่องก่อนหนี!)
  • git commit -am "rewrote entire site in angular.js - it's faster now, I'm sure" (รวบยอดการเขียนเว็บใหม่ทั้งเว็บไว้ใน Commit เดียว… ใหญ่เกินไปจนตามแก้ยาก)

✅ แบบที่ดี (Good Commits - สไตล์ Conventional):

  • feat: Added a feature to multiply integer and decimal number (ชัดเจนว่าเพิ่มฟีเจอร์อะไร)
  • docs: Added information about the project collaborators (ชัดเจนว่าอัปเดตเอกสารเรื่องไหน)
  • [#321] Stop clipping trainer meta-data on video nodes at small screen size (มีการอ้างอิงหมายเลข Ticket/Issue เพื่อให้ตามไปดูต้นตอของปัญหาได้)

6. 🏁 บทสรุป (To be continued…)

จำไว้นะครับน้องๆ การเขียน Commit Message ที่ดีคือการเขียนในระดับที่ “ทำยังไงก็ได้ให้ตัวเราในอนาคต ไม่หงุดหงิดด่าตัวเราในอดีตว่ามักง่าย” (Whatever it takes to make future me not get pissed off at past me for being lazy)

เมื่อเราเข้าใจพลังของ git add ในการแบ่งก้อนงาน และเขียน git commit ได้ราวกับนักเล่าเรื่องแล้ว โค้ดของเราจะมีประวัติศาสตร์ที่สวยงามและทีมงานจะรักเราแน่นอนครับ! ในตอนต่อไป พี่จะพาไปกระโดดข้ามมิติเวลา รู้จักกับการแตกกิ่งก้านสาขา หรือที่เรียกว่า Branching Model อย่าลืมติดตามกันนะครับ!


---
**ต้องการที่ปรึกษาด้านการวางระบบ DevOps และ Version Control ให้กับทีมหรือองค์กรของคุณ?**
ทีมงาน WP Solution พร้อมให้บริการออกแบบและวางระบบ CI/CD แบบครบวงจร 
ดูรายละเอียดบริการของเราได้ที่: [www.wpsolution2017.com](https://www.wpsolution2017.com)
หรือพูดคุยปรึกษาเบื้องต้นได้ที่ Line: wisit.p