การคอมมิต — คืออะไร กฎการจัดรูปแบบและการทำงานกับ Git

คอมมิตใน Git คืออะไร

คอมมิตใน Git คือวัตถุที่เก็บสถานะของไฟล์โปรเจกต์ ณ เวลาใดเวลาหนึ่ง แต่ละคอมมิตประกอบด้วยภาพรวมของไฟล์ที่ถูกติดตามทั้งหมด การอ้างอิงถึงคอมมิตแม่ และข้อมูลเมตา ซึ่งแตกต่างจากระบบควบคุมเวอร์ชันอื่นๆ Git ใช้ พื้นที่จัดเก็บที่ระบุตำแหน่งด้วยเนื้อหา — วัตถุแต่ละชิ้นถูกระบุด้วยแฮช SHA-1 ของเนื้อหา

เมื่อนักพัฒนาคอมมิตการเปลี่ยนแปลง Git จะสร้างวัตถุคอมมิตที่เก็บ: วัตถุ tree (โครงสร้างไฟล์), แฮชของคอมมิตแม่, ผู้เขียน, ผู้ทำคอมมิต, วันที่ และข้อความ วัตถุนี้ไม่สามารถเปลี่ยนแปลงได้ — เมื่อสร้างแล้ว คอมมิตจะไม่สามารถแก้ไขได้โดยไม่เปลี่ยนแฮชของมัน ความไม่เปลี่ยนแปลงนี้รับประกันความสมบูรณ์ของประวัติโปรเจกต์

# เตรียมการเปลี่ยนแปลงและคอมมิต
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# ดูรายละเอียดคอมมิต
git log --oneline -3
git show HEAD

# เตรียมการเปลี่ยนแปลงทั้งหมดและคอมมิตในขั้นตอนเดียว
git commit -a -m "Update dependencies to latest versions"

คอมมิตก่อตัวเป็นกราฟแบบมีทิศทางไม่มีวงจร (DAG) โดยที่คอมมิตใหม่แต่ละอันอ้างอิงถึงอันก่อนหน้า สิ่งนี้ช่วยให้สามารถนำทางผ่านประวัติ ยกเลิกการเปลี่ยนแปลง และวิเคราะห์วิวัฒนาการของฐานโค้ด การทำความเข้าใจโครงสร้างของ Git DAG เป็นพื้นฐานสำหรับการทำงานขั้นสูงกับคอมมิต

วิธีคอมมิตการเปลี่ยนแปลงอย่างถูกต้อง

กระบวนการคอมมิตใน Git ประกอบด้วยสองขั้นตอน: การเพิ่มการเปลี่ยนแปลงไปยังพื้นที่เตรียมการ (index) และการสร้างคอมมิต พื้นที่เตรียมการช่วยให้นักพัฒนาเลือกว่าการเปลี่ยนแปลงเฉพาะใดจะรวมอยู่ในคอมมิต แม้ว่าหลายไฟล์จะถูกแก้ไขในไดเรกทอรีทำงาน

กฎความเป็นอะตอมเป็นหลักการสำคัญของคอมมิตที่ดี แต่ละคอมมิตควรมี การเปลี่ยนแปลงเชิงตรรกะหนึ่งอย่าง หากนักพัฒนาแก้ไขบั๊กและปรับโครงสร้างโค้ด — สิ่งเหล่านี้ควรเป็นสองคอมมิตแยกกัน คอมมิตแบบอะตอมช่วยลดความซับซ้อนของการตรวจสอบโค้ด การย้อนกลับการเปลี่ยนแปลง และการวิเคราะห์ประวัติ

ก่อนคอมมิต ควรตรวจสอบ: ว่ายังมีเอาต์พุตการดีบัก บล็อกที่ถูกคอมเมนต์ หรือการเปลี่ยนแปลงโดยไม่ตั้งใจเหลืออยู่ในโค้ดหรือไม่ สำหรับสิ่งนี้ ใช้คำสั่ง git diff --cached ซึ่งแสดงสิ่งที่แน่นอนว่าจะรวมอยู่ในคอมมิต การตรวจสอบเพิ่มเติมด้วย git status แสดงรายการไฟล์ในพื้นที่เตรียมการ

• ตรวจสอบการเปลี่ยนแปลง — git diff --cached แสดงสิ่งที่จะรวมในคอมมิต
• ตรวจสอบคุณภาพ — โค้ดควรผ่าน linter และการทดสอบก่อนคอมมิต
• เขียนข้อความ — คำอธิบายที่ชัดเจนเกี่ยวกับวัตถุประสงค์ของการเปลี่ยนแปลง
• ตรวจสอบไฟล์ที่เตรียมไว้ — git status ยืนยันรายการไฟล์

กฎการเขียนข้อความคอมมิต

ข้อความคอมมิตคือเอกสารประกอบการเปลี่ยนแปลงสำหรับนักพัฒนาในอนาคต ข้อความที่ดีตอบคำถาม: อะไรถูกเปลี่ยนแปลงและทำไม ธรรมเนียม Conventional Commits (ทีม Angular, 2016) ได้กลายเป็นมาตรฐานสำหรับหลายโปรเจกต์และกำหนดรูปแบบ: ประเภท(ขอบเขต): คำอธิบาย

ข้อความคอมมิตที่ดีประกอบด้วยหัวเรื่อง (สูงสุด 50 ตัวอักษร) และเนื้อหา (ไม่บังคับ สูงสุด 72 ตัวอักษรต่อบรรทัด) หัวเรื่องเขียนในรูปแบบคำสั่ง: “Add” ไม่ใช่ “Added” หรือ “Adds” Capitalization และจุดท้ายหัวเรื่องไม่ใช้ — เป็นธรรมเนียมสากลของ Git

ข้อความที่ไม่ดี: “fix things” หรือ “update” — ไม่ให้ข้อมูล หนึ่งเดือนต่อมา นักพัฒนาจะไม่สามารถเข้าใจว่าอะไรถูกเปลี่ยนแปลงและทำไม ข้อความที่ดี: “fix(payment): handle timeout in stripe callback” — เห็นได้ทันทีว่าอะไรและที่ไหนถูกแก้ไข

ข้อผิดพลาดทั่วไปเมื่อคอมมิต

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

ข้อผิดพลาดที่พบบ่อยเป็นอันดับสองคือข้อความคอมมิตที่ไม่ดี ข้อความเช่น “fix”, “update”, “changes” หรือ “wip” ไม่ให้บริบทแก่นักพัฒนาในอนาคต อีกหกเดือน จะไม่มีใครจำได้ว่าอะไรถูกแก้ไขแน่นอน กฎง่ายๆ: ลองนึกภาพว่าอีกหนึ่งปีคุณกำลังดูประวัติและพยายามหาการเปลี่ยนแปลงเฉพาะอย่าง

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

ข้อผิดพลาดที่สี่คือการคอมมิตข้อมูลลับ คีย์ API รหัสผ่าน และโทเคนไม่ควรลงไปในประวัติ Git หากความลับถูกคอมมิตไปแล้ว การลบในคอมมิตใหม่ไม่เพียงพอ ต้องลบออกจากประวัติทั้งหมดผ่าน git filter-branch หรือ BFG Repo-Cleaner

เทคนิคขั้นสูงสำหรับการทำงานกับคอมมิต

Git มีเครื่องมือสำหรับจัดการประวัติคอมมิต หนึ่งในที่มีประโยชน์ที่สุดคือ git commit --amend ซึ่งช่วยให้สามารถเสริมคอมมิตล่าสุดด้วยการเปลี่ยนแปลงใหม่หรือแก้ไขข้อความ สะดวกเมื่อนักพัฒนาลืมรวมไฟล์หรือพิมพ์ผิดในข้อความ

# แก้ไขข้อความคอมมิตล่าสุด
git commit --amend -m "fix(auth): correct token validation logic"

# เพิ่มไฟล์ที่ลืมไปในคอมมิตล่าสุด
git add missed-file.txt
git commit --amend --no-edit

# รีเบสแบบโต้ตอบสำหรับ 3 คอมมิตล่าสุด
git rebase -i HEAD~3

Interactive rebase เป็นเครื่องมือที่มีประสิทธิภาพสำหรับการเขียนประวัติใหม่ ช่วยให้รวมคอมมิต (squash) เปลี่ยนข้อความ (reword) จัดลำดับใหม่ (reorder) และลบคอมมิต (drop) อย่างไรก็ตาม rebase เปลี่ยนแปลงประวัติ จึงใช้เฉพาะกับคอมมิตในเครื่องที่ยังไม่ได้ push ไปยังพื้นที่จัดเก็บระยะไกล

มีสองวิธีในการยกเลิกคอมมิต git revert สร้างคอมมิตใหม่ที่ยกเลิกการเปลี่ยนแปลงของคอมมิตก่อนหน้า — วิธีที่ปลอดภัยที่รักษาประวัติ git reset ลบคอมมิตออกจากประวัติ — อันตรายหากคอมมิตถูก push แล้ว ในการพัฒนาทีม ใช้เฉพาะ git revert สำหรับการยกเลิกคอมมิตที่เผยแพร่แล้ว