ข้ามไปยังเนื้อหา
Tayakorn
Git Handbook

Git Handbook

LEVEL 0 · ปูพื้นจากศูนย์

แบบจำลองความคิดหลัก

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

2.1 Git เก็บภาพถ่าย ไม่ใช่ส่วนต่าง

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

2.2 สามพื้นที่ที่ไฟล์เดินทางผ่าน

หัวใจของการใช้งาน Git คือเข้าใจว่าไฟล์หนึ่งไฟล์มีได้สามสถานะ อยู่ในสามพื้นที่:

Working Directoryโฟลเดอร์ที่คุณแก้ไฟล์จริงแก้ไข สร้าง ลบ ไฟล์Staging Areaพื้นที่จัดเตรียม“เลือกว่าจะใส่อะไรในภาพถ่าย”Repositoryประวัติถาวร (.git)ภาพถ่ายที่บันทึกแล้วaddcommitcheckout / restore — ดึงภาพเก่ากลับมา
FIG 2.1 add ย้ายการเปลี่ยนแปลงเข้าพื้นที่จัดเตรียม, commit ผนึกพื้นที่จัดเตรียมเป็นภาพถ่ายถาวร — แยกสองขั้นเพื่อให้ “เลือก” ได้ว่าจะบันทึกอะไร

ทำไมต้องมีพื้นที่จัดเตรียม (staging) คั่นกลาง? เพราะมันให้คุณ ประกอบ commit อย่างตั้งใจ — แก้ไปสิบไฟล์ แต่เลือก add แค่สามไฟล์ที่เป็นเรื่องเดียวกันมา commit ก่อนได้ ทำให้ประวัติแต่ละ commit เล่าเรื่องชัดเจนทีละเรื่อง ไม่ปนกันมั่ว

2.3 SHA — ลายนิ้วมือของทุกอย่าง

ทุก commit มีรหัสประจำตัวยาว 40 ตัวอักษร เช่น 9f2c1a8... รหัสนี้ไม่ได้สุ่มมา แต่คำนวณจากเนื้อหาของ commit เองทั้งหมด (ไฟล์ + ข้อความ + ผู้เขียน + commit ก่อนหน้า) ผลที่ตามมาคือสิ่งที่ลึกซึ้งมาก: ถ้าเนื้อหาเปลี่ยนแม้ตัวอักษรเดียว รหัสจะเปลี่ยนทันที — แปลว่า commit แก้ไขไม่ได้ การ "แก้ประวัติ" จริง ๆ คือการสร้าง commit ใหม่ที่มีรหัสใหม่มาแทน (เข้าใจจุดนี้แล้ว บทที่ 6, 8, 12 จะกระจ่างทันที)

สรุปบทที่ 2 — commit = ภาพถ่ายทั้งโปรเจกต์ ไม่ใช่ส่วนต่าง · ไฟล์เดินทางผ่าน 3 พื้นที่: working → staging (add) → repository (commit) · staging มีไว้ให้ประกอบ commit อย่างตั้งใจ · SHA คำนวณจากเนื้อหา ทำให้ commit แก้ไม่ได้และปลอมไม่ได้ — รากฐานของความน่าเชื่อถือทั้งหมดของ Git

อ่านแบบเต็มเล่ม