Git เก็บโค้ดทั้งโปรเจกต์ใน 41 ไบต์ได้อย่างไร

Git stores your entire project in 41 bytes — ประโยคนี้ฟังดูเหลือเชื่อ แต่มันคือความจริงทางวิศวกรรมที่อยู่เบื้องหลังระบบควบคุมเวอร์ชันที่นักพัฒนาทั่วโลกใช้งานทุกวัน ไม่ว่าโปรเจกต์ของคุณจะมีไฟล์ 10 ไฟล์หรือ 10 ล้านไฟล์ Git ก็สามารถอ้างอิง “สถานะทั้งหมด” ของโปรเจกต์ ณ เวลานั้นได้ด้วยตัวอักษรเพียง 41 ตัว บทความนี้จะพาคุณไปดูว่ากลไกเบื้องหลังนี้ทำงานอย่างไร ตั้งแต่การกด git add จนถึงการ push ขึ้น GitHub

TL;DR: Git ไม่ได้เก็บโค้ดทั้งโปรเจกต์ไว้ใน 41 ไบต์จริงๆ แต่ Git ใช้ SHA-1 hash ที่มีความยาว 40 ตัวอักษรฐาน 16 บวกอักขระขึ้นบรรทัดใหม่ 1 ตัว รวมเป็น 41 ไบต์ เพื่อเป็น “ลายนิ้วมือ” อ้างอิงถึงเนื้อหาทั้งหมดของ commit หนึ่งๆ ซึ่งข้างในมันจะโยงไปถึง tree object และ blob object ที่เก็บโค้ดจริงแบบบีบอัดด้วย zlib ไว้อีกที ระบบนี้เองที่ทำให้ Git เร็วมาก แม้แต่ Linux kernel ที่มีมากกว่า 1.2 ล้าน commit ก็ยังไล่ประวัติได้ในเวลาไม่ถึง 3 วินาที

Git คืออะไร และทำไมโค้ดทั้งโปรเจกต์ถึงย่อลงเหลือ 41 ไบต์ได้

Git คือระบบควบคุมเวอร์ชันแบบกระจายศูนย์ (distributed version control system) ที่เก็บข้อมูลเป็น “กราฟของออบเจกต์” ไม่ใช่การเก็บไฟล์ diff แบบเครื่องมือรุ่นเก่าอย่าง SVN หัวใจสำคัญคือทุกๆ ชิ้นข้อมูลใน Git ไม่ว่าจะเป็นไฟล์ โฟลเดอร์ หรือ commit ล้วนถูกแปลงเป็น SHA-1 hash ความยาวคงที่ นั่นหมายความว่าต่อให้โปรเจกต์คุณมีขนาดหลายกิกะไบต์ Git ก็สามารถอ้างอิงสถานะทั้งหมด ณ จุดใดจุดหนึ่งได้ด้วยสตริงสั้นๆ เพียง 41 ไบต์ ซึ่งก็คือ commit hash นั่นเอง

เรื่องน่าสนใจคือ Git เกิดขึ้นจากสถานการณ์ที่ค่อนข้างกดดัน Linus Torvalds ผู้สร้าง Linux kernel เขียน Git ขึ้นมาภายในเวลาเพียง 10 วันในเดือนเมษายน 2005 หลังจากบริษัท BitKeeper ซึ่งเป็นเครื่องมือ version control ที่ทีม Linux kernel ใช้อยู่ ประกาศยกเลิกไลเซนส์แบบฟรีที่เคยให้กับนักพัฒนาโอเพนซอร์ส Linus จึงต้องสร้างเครื่องมือใหม่ที่เร็วพอจะรองรับ contributor นับพันคนทั่วโลก และผลลัพธ์ที่ได้ก็คือระบบที่ใช้แนวคิด content-addressable storage ซึ่งเป็นรากฐานของทุกอย่างที่เราจะอธิบายต่อจากนี้

สิ่งที่ต้องเตรียมก่อนเริ่ม

ก่อนลงมือทดลองตามบทความนี้ คุณควรมีพื้นฐานดังนี้

• ติดตั้ง Git เวอร์ชัน 2.x ขึ้นไปบนเครื่อง (เช็กด้วยคำสั่ง git --version)
• เข้าใจคำสั่งพื้นฐาน เช่น git init, git add, git commit
• มี terminal หรือ command line พร้อมใช้งาน (macOS/Linux ใช้ Terminal, Windows ใช้ Git Bash)
• สมัครบัญชี GitHub ไว้ล่วงหน้า หากต้องการทดลองขั้นตอนการ push จริง

ถ้าคุณอยากรู้วิธีใช้ AI ช่วยเขียนโค้ดควบคู่กับ Git ลองอ่าน รีวิว GitHub Copilot 2026 — คุ้มค่าไหม? ใช้งานยังไง? เพิ่มเติม เพราะการเข้าใจกลไก Git ภายในจะช่วยให้คุณ debug ปัญหา merge conflict หรือ commit history ได้แม่นยำขึ้นมาก

ขั้นตอนโดยละเอียด: Git เก็บโค้ดเป็น 41 ไบต์ได้อย่างไร

ขั้นตอนที่ 1: กด git add แล้ว Git บีบอัดไฟล์ด้วย zlib

เมื่อคุณรันคำสั่ง git add Git จะไม่ได้แค่ “จำไว้ว่ามีไฟล์นี้” แต่จะอ่านเนื้อหาไฟล์ทั้งหมด แล้วบีบอัดด้วยอัลกอริทึม zlib deflate จากนั้นคำนวณ SHA-1 hash จากข้อมูลที่บีบอัดแล้ว กระบวนการนี้เกิดขึ้นทันทีตอน stage ไฟล์ ไม่ใช่ตอน commit ซึ่งเป็นเหตุผลที่ Git สามารถตรวจจับได้ทันทีว่าไฟล์เดิมถูกแก้ไขหรือไม่ เพราะแค่เปรียบเทียบ hash ก็รู้แล้ว

ขั้นตอนที่ 2: สร้าง blob object เก็บไว้ใน .git/objects

Git นำเนื้อหาที่บีบอัดแล้วไปเก็บเป็น “blob object” ในโฟลเดอร์ .git/objects/[2 ตัวแรกของ hash]/[38 ตัวที่เหลือ] การออกแบบแบบนี้ไม่ใช่เรื่องบังเอิญ เพราะ .git/objects ใช้อักขระ 2 ตัวแรกของ SHA-1 hash เป็นชื่อโฟลเดอร์ ทำให้เกิดโฟลเดอร์ย่อยได้สูงสุดพอดี 256 โฟลเดอร์ (16×16 จากเลขฐาน 16) ซึ่งช่วยให้ filesystem ไม่ต้องจัดการไฟล์จำนวนมหาศาลในโฟลเดอร์เดียว ทำให้การค้นหาและเขียนไฟล์เร็วขึ้นอย่างมีนัยสำคัญเมื่อโปรเจกต์มีออบเจกต์นับแสนนับล้านชิ้น

ขั้นตอนที่ 3: git commit สร้าง tree object

เมื่อคุณรัน git commit Git จะสร้าง “tree object” ซึ่งทำหน้าที่เหมือนสารบัญของโฟลเดอร์ มันจะแมปชื่อไฟล์แต่ละไฟล์เข้ากับ SHA-1 hash ของ blob object ที่เกี่ยวข้อง และถ้าโปรเจกต์มีโฟลเดอร์ย่อย tree object ก็จะอ้างอิงถึง tree object อื่นซ้อนกันเป็นชั้นๆ ตามโครงสร้างไดเรกทอรีจริง นี่คือจุดที่ Git แปลง “ไฟล์และโฟลเดอร์” ทั้งหมดให้กลายเป็นกราฟของ hash ที่เชื่อมโยงกัน

ขั้นตอนที่ 4: สร้าง commit object ที่รวมทุกอย่างเข้าด้วยกัน

ขั้นตอนถัดมา Git จะสร้าง “commit object” ซึ่งบรรจุ hash ของ tree object ราก, hash ของ commit ก่อนหน้า (parent), ข้อมูลผู้เขียน, timestamp และข้อความ commit message ทั้งหมดนี้ถูกเขียนเป็นข้อความธรรมดาก่อน แล้วจึงนำไปคำนวณ hash ในขั้นต่อไป

ขั้นตอนที่ 5: คำนวณ SHA-1 hash ของ commit object

commit object ที่เพิ่งสร้างจะถูกคำนวณ SHA-1 hash ของตัวมันเองอีกที จากเนื้อหาทั้งหมดที่รวมกันในขั้นตอนที่ 4 ผลลัพธ์ก็คือ hash ยาว 40 ตัวอักษรบวกอักขระขึ้นบรรทัดใหม่ รวมเป็น 41 ไบต์ที่เรากำลังพูดถึงตลอดทั้งบทความ และเพราะ hash นี้คำนวณจาก parent hash ด้วย มันจึงสร้าง “chain” ที่เปลี่ยนแปลงไม่ได้ (immutable cryptographic chain) — ถ้าใครแก้ไขโค้ดใน commit เก่าแม้แต่ตัวอักษรเดียว hash ของ commit นั้นและทุก commit ที่ตามมาจะเปลี่ยนทั้งหมด

ระบบที่ดูแลซอร์สโค้ดของนักพัฒนาหลายร้อยล้านคนทั่วโลกในวันนี้ ถูกเขียนขึ้นโดยคนคนเดียวภายในเวลาแค่ 10 วัน — และหัวใจของมันคือสตริงยาว 41 ตัวอักษรที่แทนสถานะทั้งจักรวาลของโค้ดได้

ขั้นตอนที่ 6: อัปเดต HEAD ให้ชี้ไปที่ commit ใหม่

หลังจากได้ commit hash แล้ว Git จะอัปเดตไฟล์ reference ในโฟลเดอร์ .git/refs/heads/[ชื่อ branch] ให้ชี้ไปยัง SHA-1 hash ของ commit ใหม่ ไฟล์นี้จริงๆ แล้วก็เป็นแค่ text file เล็กๆ ที่บรรจุ hash 41 ไบต์นั้นอยู่ข้างใน นี่คือเหตุผลที่การสลับ branch ใน Git ทำได้เร็วมาก เพราะแค่เปลี่ยนตัวชี้ ไม่ต้องคัดลอกไฟล์ทั้งหมด

ขั้นตอนที่ 7: push ขึ้น GitHub ด้วย delta compression

เมื่อคุณ push โค้ดขึ้น GitHub Git จะไม่ส่งไฟล์ทั้งหมดซ้ำ แต่คำนวณ delta compression เปรียบเทียบออบเจกต์บนเครื่องคุณกับออบเจกต์ที่ remote มีอยู่แล้ว แล้วส่งเฉพาะส่วนต่างผ่าน HTTP หรือ SSH ในรูปแบบ pack file ทำให้การ push แม้แต่โปรเจกต์ขนาดใหญ่ก็ยังใช้แบนด์วิดท์น้อยกว่าที่คาดคิดมาก

ขั้นตอนที่ 8: GitHub ตรวจสอบและอัปเดต branch แบบ atomic

ฝั่ง GitHub เมื่อรับ pack file แล้ว จะตรวจสอบความถูกต้องของ SHA-1 ทุกออบเจกต์ก่อน เพื่อยืนยันว่าข้อมูลไม่เสียหายระหว่างทาง จากนั้นจึงอัปเดต remote branch reference แบบ atomic คือสำเร็จทั้งหมดหรือไม่สำเร็จเลย ไม่มีสถานะครึ่งๆ กลางๆ ซึ่งเป็นเหตุผลที่ Git แทบไม่เคย “ทำ repository พัง” แม้ push ระหว่างทางจะหลุดก็ตาม

ตัวอย่างโค้ดสมบูรณ์

ลองทำตามตัวอย่างนี้เพื่อดูกลไกทั้งหมดด้วยตาตัวเอง

mkdir git-demo && cd git-demo
git init

echo "Hello Git" > hello.txt
git add hello.txt

# ดู hash ของไฟล์ที่เพิ่ง stage
git hash-object hello.txt
# ผลลัพธ์ตัวอย่าง: 557db03de997c86a4a028e1ebd3a1ceb225be238

git commit -m "first commit"

# ดู commit hash ล่าสุด (40 ตัวอักษร + newline = 41 ไบต์)
git rev-parse HEAD

# ดูว่าไฟล์นี้ถูกเก็บอยู่ที่ไหนใน .git/objects
find .git/objects -type f

# แกะเนื้อหาออบเจกต์ดูเนื้อหาจริงที่ถูกบีบอัดไว้
git cat-file -p HEAD
git cat-file -p HEAD^{tree}

อธิบายทีละคำสั่ง: git hash-object แสดง SHA-1 hash ที่ Git คำนวณจากเนื้อหาไฟล์ (ไม่รวมชื่อไฟล์) git rev-parse HEAD จะคืนค่า commit hash ปัจจุบันซึ่งมีความยาว 40 ตัวอักษรพอดี find .git/objects -type f ช่วยให้เห็นว่า Git แยกโฟลเดอร์ตาม 2 ตัวอักษรแรกของ hash จริงตามที่อธิบายไปในขั้นตอนที่ 2 ส่วน git cat-file -p ใช้ถอดรหัส (decompress) ออบเจกต์ออกมาดูเนื้อหาจริงแบบมนุษย์อ่านได้ ทั้งใน commit object และ tree object

เคล็ดลับและข้อควรระวัง

• SHA-1 ไม่ใช่การเข้ารหัสลับ (encryption) — มันเป็นฟังก์ชันแฮชทางเดียว ใช้ยืนยันความถูกต้องของข้อมูล (integrity) ไม่ใช่ซ่อนเนื้อหา ใครก็ตามที่มีสิทธิ์เข้าถึง repository ยังเห็นโค้ดจริงได้ตามปกติ
• อย่าลบไฟล์ใน .git/objects ด้วยมือ เพราะถ้าออบเจกต์หายไป Git อาจไล่ history ไม่ครบ ควรใช้คำสั่งอย่าง git gc หรือ git prune แทน
• โปรเจกต์ขนาดใหญ่ก็ยังเร็วอยู่ — Linux kernel repository มีมากกว่า 1.2 ล้าน commit นับถึงปี 2024 แต่ Git ยังไล่ประวัติทั้งหมดได้ภายในเวลาไม่ถึง 3 วินาที ด้วยเทคนิค commit graph optimization ที่แคชความสัมพันธ์ระหว่าง commit ไว้ล่วงหน้า
• commit message ก็มีผลต่อ hash — เพราะข้อความ commit เป็นส่วนหนึ่งของ commit object ถ้าคุณ amend เปลี่ยนแค่ข้อความ hash ก็จะเปลี่ยนทั้งหมด ทำให้เกิด commit ใหม่จริงๆ ไม่ใช่แค่แก้ข้อความในของเดิม

หากสนใจเรื่อง internal ของเครื่องมือ dev อื่นๆ เพิ่มเติม สามารถดูบทความในหมวด Coding หรือหมวด Explainer ของเราได้เช่นกัน

ขั้นตอนต่อไป

ตอนนี้คุณเข้าใจแล้วว่าทำไม Git ถึงอ้างอิงโปรเจกต์ทั้งหมดด้วย hash 41 ไบต์ได้ ขั้นตอนต่อไปที่แนะนำคือลองสำรวจคำสั่ง git log --graph เพื่อดูกราฟความสัมพันธ์ของ commit หรือลองอ่านซีรีส์เจาะลึก Git internals เพิ่มเติมได้ที่ Git เก็บโค้ดทั้งโปรเจกต์ใน 41 ไบต์ได้อย่างไร (ตอนต่อขยาย) และถ้าอยากรู้เบื้องหลังของแพลตฟอร์มที่ทำให้ Git ใช้งานง่ายขึ้นสำหรับทีม อย่าง GitHub ที่เริ่มต้นจากโค้ด Ruby on Rails โดยทีมเล็กๆ เพียง 3 คนด้วยเงินทุน 100,000 ดอลลาร์ในปี 2007 ก็น่าศึกษาไม่แพ้กัน

แต่ยังมีคำถามที่ลึกกว่านั้นอีกขั้น: ถ้า SHA-1 hash มีความยาวจำกัดแค่ 40 ตัวอักษร แล้วถ้าวันหนึ่งนักพัฒนาสองคนสร้างไฟล์ที่ได้ hash ซ้ำกันขึ้นมาโดยบังเอิญล่ะ จะเกิดอะไรขึ้น? คำตอบนี้เผยให้เห็นจุดอ่อนที่ซ่อนอยู่ของ Git ซึ่งเราจะเจาะลึกในบทความถัดไป

คำถามที่พบบ่อย (FAQ)

Git ใช้อัลกอริทึมอะไรในการสร้าง hash?

A: Git ใช้ SHA-1 (Secure Hash Algorithm 1) เป็นค่าเริ่มต้นในการคำนวณ hash ของทุกออบเจกต์ ไม่ว่าจะเป็น blob, tree หรือ commit โดยผลลัพธ์ที่ได้คือสตริงฐาน 16 ความยาว 40 ตัวอักษร ซึ่งเมื่อรวมกับอักขระขึ้นบรรทัดใหม่ตอนแสดงผลจะกลายเป็น 41 ไบต์ Git เวอร์ชันใหม่ๆ เริ่มรองรับ SHA-256 เป็นทางเลือกแล้วเช่นกัน แต่ SHA-1 ยังคงเป็นค่ามาตรฐานที่ใช้กันแพร่หลายที่สุด

ตัวเลข 41 ไบต์มาจากไหน?

A: มาจาก SHA-1 hash ที่มีความยาว 40 ตัวอักษรฐาน 16 (hexadecimal) บวกกับอักขระขึ้นบรรทัดใหม่ (newline) อีก 1 ไบต์ตอนที่ Git เขียนค่านี้ลงในไฟล์ reference เช่นใน .git/refs/heads/ รวมเป็น 41 ไบต์พอดี ค่านี้เองที่ใช้แทนสถานะทั้งหมดของ commit หนึ่งๆ ได้อย่างสมบูรณ์

ทำไม Git ถึงเร็วแม้โปรเจกต์จะมีขนาดใหญ่มาก?

A: เพราะ Git ออกแบบให้แต่ละออบเจกต์ไม่เปลี่ยนแปลง (immutable) และใช้ hash เป็นตัวชี้แทนการคัดลอกข้อมูลซ้ำ บวกกับการจัดโฟลเดอร์ .git/objects ด้วย 2 ตัวอักษรแรกของ hash ที่สร้างได้สูงสุด 256 โฟลเดอร์ย่อย ทำให้ filesystem ค้นหาไฟล์ได้เร็ว รวมถึงเทคนิค commit graph optimization ที่ทำให้แม้แต่ Linux kernel ที่มีมากกว่า 1.2 ล้าน commit ก็ยังไล่ประวัติได้ภายในไม่ถึง 3 วินาที

Git กับ GitHub ต่างกันอย่างไร?

A: Git คือซอฟต์แวร์ version control ที่รันบนเครื่องของคุณ ส่วน GitHub คือแพลตฟอร์มออนไลน์ที่สร้างขึ้นครอบ Git อีกที เพื่อให้ทีมทำงานร่วมกัน รีวิว pull request และโฮสต์โค้ดไว้บนคลาวด์ GitHub เริ่มต้นพัฒนาในเดือนตุลาคม 2007 โดย Tom Preston-Werner, Chris Wanstrath และ PJ Hyett ด้วยโค้ดเบสที่เขียนด้วย Ruby on Rails และเงินทุนตั้งต้นเพียง 100,000 ดอลลาร์ ก่อนจะเติบโตกลายเป็นแพลตฟอร์มที่มีนักพัฒนานับร้อยล้านคนใช้งานในปัจจุบัน

อัปเดตล่าสุด: 14 September 2026 บน AiDevThai