วิวัฒนาการของ Git สำหรับอีก 10 ปีข้างหน้า

 (lwn.net)
21 คะแนน โดย GN⁺ 2026-02-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Git ที่นักพัฒนาทั่วโลกใช้งาน กำลังผลักดันการเปลี่ยนแปลงเชิงโครงสร้างเพื่อเตรียมพร้อมสำหรับอีก 10 ปีข้างหน้า โดยมีการปรับปรุงหลักที่เน้นด้าน ความปลอดภัย ความสามารถในการขยายตัว และความใช้งานง่าย
  • การเปลี่ยนแปลงที่เห็นได้ชัดที่สุดคือ การเปลี่ยนจาก SHA-1 ไปเป็น SHA-256 โดยมีแผนจะยกเลิกการใช้ SHA-1 ภายในปี 2030 แต่การนำมาใช้ยังล่าช้าเพราะระบบนิเวศยังรองรับไม่เพียงพอ
  • กำลังมีความพยายามนำ Reftable มาใช้ เพื่อจัดการรีเฟอเรนซ์หลายล้านรายการอย่างมีประสิทธิภาพ และแก้ข้อจำกัดของไฟล์ซิสเต็มรวมถึงปัญหาด้าน concurrency
  • เพื่อปรับปรุงการจัดการไฟล์ขนาดใหญ่ จึงมีการพัฒนา Large-object promisors และ ฐานข้อมูลอ็อบเจ็กต์แบบปลั๊กอิน โดยกำลังผสานเข้ากับ Git ทีละขั้นตั้งแต่เวอร์ชันหลัง Git 2.50 เป็นต้นไป
  • ภายใต้อิทธิพลของระบบควบคุมเวอร์ชันรุ่นใหม่อย่าง Jujutsu นั้น Git กำลังพยายามรองรับเวิร์กโฟลว์สมัยใหม่ผ่านการทำ UI ให้ง่ายขึ้นและเพิ่มคำสั่งใหม่

เหตุผลที่ Git ต้องเปลี่ยนแปลง

  • นับตั้งแต่เปิดตัวในปี 2005 Git ได้กลายเป็นเครื่องมือสำคัญที่มีรีโพซิทอรีหลายล้านแห่งและสคริปต์จำนวนมากพึ่งพามาตลอด 20 ปี
    • อย่างไรก็ตาม การเปลี่ยนแปลงของสภาพแวดล้อม เช่น ช่องโหว่ความปลอดภัยของ SHA-1, การเพิ่มขึ้นของรีโพซิทอรีขนาดใหญ่ และ การแพร่หลายของ CI pipeline ได้เผยให้เห็นข้อจำกัดเชิงโครงสร้าง
  • ความเป็นไปได้ของการชนกันของ SHA-1 ได้รับการพิสูจน์แล้วจาก การโจมตี SHAttered ของ CWI และ Google ในปี 2017
    • จากพลังการประมวลผล GPU ที่เพิ่มขึ้น ทำให้องค์กรขนาดใหญ่เข้าถึงระดับที่สามารถคำนวณ hash collision ได้
  • Git จำเป็นต้องเลือก วิวัฒนาการแบบค่อยเป็นค่อยไป แทนการออกแบบใหม่แบบพลิกโฉม และกำลังผลักดันการเปลี่ยนแปลงโดยยังคงความเข้ากันได้กับระบบนิเวศเดิม

การเปลี่ยนไปใช้ SHA-256

  • Git 2.29 (ตุลาคม 2020) เพิ่ม การรองรับ SHA-256 แล้ว แต่แพลตฟอร์มหลักอย่าง GitHub ยังไม่รองรับ
    • Git, Dulwich และ Forgejo รองรับเต็มรูปแบบ ส่วน GitLab, go-git และ libgit2 ยังอยู่ในขั้นรองรับแบบทดลอง
  • แม้ SHA-1 จะถูกใช้เพื่อการตรวจสอบความถูกต้องของข้อมูลเป็นหลัก แต่ทั้งระบบนิเวศที่เกี่ยวข้องกับ ลายเซ็น, CI และสคริปต์ ต่างทำงานบนสมมติฐานเรื่องความทนทานต่อการชนกัน
  • ตามข้อกำหนดของภาครัฐและภาคธุรกิจ จำเป็นต้องถอด SHA-1 ออกภายในปี 2030 และมีแผนให้ SHA-256 เป็นค่าเริ่มต้นใน Git 3.0
  • เพื่อให้การเปลี่ยนผ่านในระบบนิเวศเกิดขึ้นได้ จึงแนะนำให้ผู้ใช้มีส่วนร่วมผ่าน การทดสอบเครื่องมือและการขอให้ฟอร์จรองรับ

การนำ Reftable มาใช้

  • Git แบบเดิมใช้ โครงสร้าง loose reference ที่เก็บแต่ละรีเฟอเรนซ์เป็นไฟล์แยกกัน
    • ในรีโพซิทอรีที่มีรีเฟอเรนซ์หลายสิบล้านรายการ วิธีนี้ไม่มีประสิทธิภาพ และก่อให้เกิดทั้ง ปัญหาการแยกตัวพิมพ์เล็กใหญ่ของไฟล์ซิสเต็ม และ ความไม่สอดคล้องกันด้าน concurrency
  • Reftable เป็น โครงสร้างตารางบนฟอร์แมตไบนารี ที่ช่วยให้ทำ atomic update และจัดการรีเฟอเรนซ์ได้อย่างมีประสิทธิภาพ
    • ในกรณีของรีโพซิทอรีที่ GitLab มีรีเฟอเรนซ์ 20 ล้านรายการ ไฟล์ packed-refs แบบเดิมต้องเขียนใหม่ถึง 2GB
  • ใน Git 3.0 จะเปลี่ยนให้ Reftable เป็นแบ็กเอนด์เริ่มต้น และแนะนำให้ ใช้คำสั่ง Git แทนการเข้าถึงไฟล์โดยตรง

การปรับปรุงการจัดการไฟล์ขนาดใหญ่

  • Git มีประสิทธิภาพกับการบีบอัดไฟล์ข้อความ แต่เมื่อ ไฟล์ไบนารีถูกแก้ไข จะต้องสร้างอ็อบเจ็กต์ทั้งหมดขึ้นใหม่ ทำให้เกิดความไม่มีประสิทธิภาพ
    • จากการวิเคราะห์ของ GitLab พบว่า 75% ของพื้นที่รีโพซิทอรีถูกใช้โดยไฟล์ไบนารีขนาด 1MB ขึ้นไป
  • ฟีเจอร์ Large-object promisors จะเก็บอ็อบเจ็กต์ขนาดใหญ่ไว้ในรีโมตสตอเรจแยกต่างหาก เพื่อให้ส่งผ่าน CDN หรือ S3 API ได้
    • มีการทำ implementation ของโปรโตคอลเสร็จแล้วใน Git 2.50~2.52 และอยู่ในขั้นที่ฝั่งไคลเอนต์สามารถใช้งานได้
  • ฐานข้อมูลอ็อบเจ็กต์แบบปลั๊กอิน จะนำฟอร์แมตจัดเก็บเฉพาะสำหรับไบนารีมาใช้ เพื่อรองรับการจัดเก็บแบบ incremental ในอนาคต
    • Git 2.53 เพิ่มอินเทอร์เฟซฐานข้อมูลอ็อบเจ็กต์แบบรวมศูนย์ และคาดว่าจะมี proof of concept (PoC) ใน 2.54

การปรับปรุงส่วนติดต่อผู้ใช้

  • คำสั่งของ Git ถูกวิจารณ์มาอย่างต่อเนื่องว่าซับซ้อนและขาดความสม่ำเสมอ ขณะที่ Jujutsu (JJ) ที่พัฒนาด้วย Rust กำลังถูกจับตามองในฐานะทางเลือก
    • Jujutsu มีความสามารถอย่าง การจัดเรียงประวัติใหม่โดยอัตโนมัติ, การจัดการ conflict ในฐานะข้อมูล, และ แนวทางที่มอง commit เป็นเหมือนฉบับร่าง
  • Git กำลังนำข้อดีบางส่วนของ Jujutsu มาใช้ โดยไม่ทำลายเวิร์กโฟลว์เดิม
    • ใน Git 2.54 มีแผนเพิ่มคำสั่ง git history split และ git history reword
    • ในอนาคตยังมีแผนเพิ่ม ซับคอมมานด์สำหรับแก้ไขประวัติ อีกมากขึ้น
  • Steinhardt เน้นว่า Git กำลังเรียนรู้ผ่านการแข่งขัน และ การทำ UI ให้ทันสมัยกับการยกระดับ usability กำลังเดินหน้าอยู่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-16
ความคิดเห็นจาก Hacker News

  • Git เป็นซอฟต์แวร์ที่ งดงามจริง ๆ แต่ก็มีด้านที่เผยให้เห็นความซับซ้อนแบบที่ยึดโปรแกรมเมอร์เป็นศูนย์กลางอยู่ตรง ๆ
    เคยลองสอน Git ให้คนที่ไม่ได้อยู่สายพัฒนา แล้วพวกเขาก็ไม่ได้ใช้ประโยชน์จาก พลังอันละเอียดอ่อน ของมันได้อย่างเต็มที่
    เว็บไซต์อย่าง Learn Git Branching เป็นแหล่งเรียนรู้ที่ยอดเยี่ยม ถ้า UX แบบนี้ถูกหลอมรวมอยู่ในประสบการณ์พื้นฐานของ Git ก็น่าจะดี — อย่างเช่นค่าเริ่มต้นที่เข้าใจง่าย และลำดับการเรียนรู้แบบค่อยเป็นค่อยไป
    ทุกวันนี้ถ้าใช้ agent CLI อย่าง Claude, Codex, OpenCode ก็สามารถมอบประสบการณ์แบบนี้ได้ไม่ยาก แต่ถ้า Git เองมี abstraction ที่เข้าถึงง่ายกว่านี้ ก็น่าจะทำให้ทุกอย่างง่ายขึ้นมาก

    • ปัญหาไม่ใช่การที่ Git เผยความซับซ้อนออกมา แต่เป็นการที่มันอธิบายความซับซ้อนนั้นผ่าน คำศัพท์และแนวคิดที่ไม่เหมาะสม รวมถึงเอกสารที่ยุ่งเหยิงต่างหาก

  • ตั้งตารอ Git 3.0 มาก แต่ขณะเดียวกันก็พร้อมจะ ผิดหวัง ได้ทันทีเหมือนกัน 😅
    jj ช่วยผู้ใช้ Git ได้มาก เพราะมันแสดงให้เห็นว่า VCS frontend ที่ใช้งานเข้าใจง่ายกว่า นั้นเป็นไปได้จริง

    • ยิ่งมีการแข่งขันมากเท่าไร ก็ยิ่งเป็น แรงกระตุ้นที่ดี ต่อ ecosystem

  • เคยเห็นกรณีใน GitLab ที่มีการเขียนไฟล์ packed-refs ขนาด 2GB ทับใหม่ทุก ๆ ไม่กี่วินาที แล้วก็ไม่เข้าใจเลยว่า “ทำไมเรื่องแบบนี้ถึงเกิดขึ้นได้”

    • และพูดตามตรง ก็ไม่แน่ใจเหมือนกันว่านี่เป็นเรื่องที่ Git หรือคนคนนั้น ควรต้องสนใจ หรือเปล่า

  • การเก็บไฟล์ขนาดใหญ่ไว้ภายนอกดูเหมือนเป็นการก้าวไปสู่โมเดลแบบรวมศูนย์ แต่ก็ขัดกับ ปรัชญาการออกแบบดั้งเดิม ของ Git

    • ไม่จำเป็นต้องเป็นแบบนั้นเสมอไป นั่นเป็นแค่เรื่องของ โมเดลการระบุตำแหน่งกับอินเทอร์เฟซ เท่านั้น จะใช้ repository แบบรวมศูนย์ก็ได้ หรือจะใช้ distributed storage อย่าง IPFS ก็ได้
    • เห็นด้วย Git เป็น DVCS ไม่ใช่ DVFS แบบอเนกประสงค์ ฉันต้องการ DVFS สำหรับเก็บเอกสารเลยสร้างขึ้นมาเอง มันเรียบง่าย เร็ว และทำงานได้เหมาะกับจุดประสงค์

  • การเปลี่ยนผ่านออกจาก SHA1 กินเวลานานเกินไป
    ฟังก์ชันแฮชน่าจะถูกออกแบบให้มี โครงสร้างแบบ modular มากกว่านี้ตั้งแต่แรก

  • คิดว่า Git ควรมีฟีเจอร์สำหรับ ติดตามไลเซนส์ซอฟต์แวร์ ในระดับ commit

    • ไม่แน่ใจว่าเข้าใจความหมายทั้งหมดไหม แต่เรื่องนั้นไม่ใช่หน้าที่ของ Git Git เป็นแค่ ระบบจัดการซอร์สโค้ด และฟีเจอร์เพิ่มเติมควรถูกทำผ่าน เครื่องมือเสริม อย่าง git-annex มากกว่า
    • ถ้า Git มีฟีเจอร์แบบนั้นเองน่าจะแย่กว่า เพราะใน commit ก็สามารถเก็บข้อมูลแบบกำหนดเองได้อยู่แล้ว ถ้าต้องการ metadata อะไรก็ใส่ไว้ใน commit แล้วให้เครื่องมือแยกต่างหากมาจัดการก็พอ
    • ใช้ trailer แบบเดียวกับโค้ดที่มี LLM ช่วยก็ได้
      ตัวอย่าง: Co-Authored-By: Whatever LLM, License: WTFPL