15Repo ใหญ่ & บทสรุป

15.1 เมื่อ repo เริ่มอืด

repo ที่โตมาก (ประวัติยาว ไฟล์เยอะ) จะเริ่มช้า เครื่องมือที่ช่วย:

• shallow clone — git clone --depth 1 ดึงแค่ commit ล่าสุด ไม่เอาประวัติทั้งหมด เหมาะกับ CI ที่ต้องการแค่โค้ดล่าสุด
• Git LFS — ไฟล์ใหญ่ที่ไม่ใช่โค้ด (วิดีโอ, โมเดล, รูปความละเอียดสูง) ไม่เหมาะเก็บใน Git ตรง ๆ เพราะทุกเวอร์ชันถูกเก็บครบ LFS เก็บไฟล์จริงแยกที่อื่น เหลือไว้ใน repo แค่ตัวชี้
• git gc — เก็บกวาด object ที่ลอยและบีบอัดเป็น packfile (ปกติ Git ทำเองเป็นระยะ)

15.2 บทสรุปทั้งเล่ม — แก่นที่ถือกลับไป

ถ้าจำได้แค่ไม่กี่อย่างจากทั้งเล่ม ขอให้เป็นสิ่งเหล่านี้ เพราะทุกคำสั่งงอกออกมาจากมัน:

• commit คือ ภาพถ่ายทั้งโปรเจกต์ ที่มี SHA ผูกกับเนื้อหา — จึงแก้ไม่ได้ ปลอมไม่ได้ และเป็นรากของความน่าเชื่อถือทั้งหมด
• ไฟล์เดินทางผ่าน สามพื้นที่ (working → staging → repository) — เข้าใจสิ่งนี้แล้ว add/commit/restore/reset เป็นเรื่องเดียวกันหมด
• branch เป็นแค่ ป้ายชี้ commit — merge, rebase, reset ล้วนคือการขยับป้ายและผูกสายประวัติ
• เกือบทุกอย่าง กู้คืนได้ ถ้าเคย commit — reflog คือตาข่ายนิรภัย กล้าทดลองได้เต็มที่
• เส้นแบ่งเดียวที่ต้องเคารพ: อย่าเขียนประวัติที่แชร์กับคนอื่นไปแล้ว

✅ สรุปบทที่ 15 — repo ใหญ่ใช้ shallow clone, Git LFS สำหรับไฟล์ใหญ่, gc เก็บกวาด · แก่นทั้งเล่ม: commit = ภาพถ่ายที่แก้ไม่ได้ · สามพื้นที่ · branch = ป้ายชี้ · กู้คืนได้เสมอด้วย reflog · ห้ามแตะประวัติที่แชร์แล้ว — เท่านี้คุณก็จาก 0 ถึง Hero แล้ว

— จบหลักสูตร —

เล่มต่อไป: git push แล้วเกิดอะไรต่อ?#

ตลอดเล่มนี้ทุกอย่างจบลงที่ git push — งานของคุณขึ้นไปอยู่บนเซิร์ฟเวอร์แล้ว แต่มีคำถามที่ค้างอยู่: ใครเป็นคนตรวจว่าโค้ดที่เพิ่งรวมเข้ามายัง build ได้ เทสต์ผ่าน และไม่ทำของเดิมพัง? ถ้าให้คนนั่งตรวจเองทุกครั้ง ทุกอย่างจะช้าและพลาดง่าย คำตอบคือ CI/CD — การให้เครื่องตรวจและส่งมอบโค้ดอัตโนมัติทุกครั้งที่คุณ push หรือเปิด Pull Request

มันคือก้าวต่อจากตรงนี้พอดี: เหตุการณ์ใน Git ที่คุณเรียนมาทั้งเล่ม (push, PR, tag) คือ "ทริกเกอร์" ที่ปลุกสายการตรวจสอบและ deploy ให้ทำงานเอง

อ่านต่อ: System Design#

เข้าใจกลไกของ Git แล้ว รู้วิธีจัดการโค้ดของทีมให้ปลอดภัยและย้อนกลับได้ — แต่โค้ดที่ push ไปแล้วต้องรันบนระบบที่รับมือกับผู้ใช้จริงได้ System Design พาไปจากคำถาม "จัดการโค้ดอย่างไร" สู่ "ระบบที่ deploy ไปแล้วต้องออกแบบอย่างไรให้ scale ได้จริง" ตั้งแต่เซิร์ฟเวอร์เครื่องเดียวไปจนถึง production พร้อม auth และความปลอดภัย · เปิดอ่าน System Design Handbook →

---

Git 0 → Hero — คู่มือฉบับเข้าใจถึงแก่น · เขียนเป็นภาษาไทย พร้อมไดอะแกรมทุกหัวข้อ

วิธีใช้ให้คุ้ม: อ่านไล่ระดับ อย่าข้าม Level 0–1 แม้จะใช้ Git เป็นแล้ว เพราะแบบจำลองความคิดในบทต้นคือกุญแจของบทท้าย · ลองทุกคำสั่งใน repo ทดลองที่พังได้