อนาคตของไฟล์ขนาดใหญ่ใน Git คือ Git เอง

 (tylercipriani.com)
13 คะแนน โดย GN⁺ 2025-08-16 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp
  • โปรเจกต์ Git เพิ่งเริ่มลงมือแก้ปัญหาการจัดการไฟล์ขนาดใหญ่อย่างเป็นทางการด้วยตัวเอง
  • Git LFS เป็นเพียงทางออกชั่วคราวที่สร้างต้นทุนหลายด้านและการผูกติดกับผู้ให้บริการสำหรับผู้ใช้
  • ช่วงหลังฟีเจอร์ partial clone ทำให้ Git เพียงอย่างเดียวสามารถทดแทนบทบาทส่วนใหญ่ของ LFS ได้แล้ว
  • ต่อจากนี้ โซลูชันใหม่ชื่อ large object promisor ก็กำลังเตรียมถูกรวมเข้าใน Git อย่างเป็นทางการ
  • จากการเปลี่ยนแปลงเหล่านี้ แนวโน้มคือคำตอบระยะยาวของการจัดการไฟล์ขนาดใหญ่จะกลับมาจบที่ Git เอง ไม่ใช่ส่วนขยายภายนอก

ปัญหาไฟล์ขนาดใหญ่ของ Git และการเปลี่ยนแปลง

  • ถ้าจะบอกว่าศัตรูตัวฉกาจที่สุดของ Git คือ ไฟล์ขนาดใหญ่ ก็คงไม่ผิด
  • ไฟล์ขนาดใหญ่ทำให้รีโพซิทอรีของ Git พองตัวขึ้น ทำให้ git clone ช้าลง และส่งผลเสียต่อสภาพแวดล้อมโฮสติ้งส่วนใหญ่ด้วย

การมาของ Git LFS และข้อจำกัด

  • ในปี 2015 GitHub เปิดตัว Git LFS เพื่อหลีกเลี่ยงปัญหาไฟล์ขนาดใหญ่
  • แต่ตัว Git LFS เองก็เพิ่มความซับซ้อนใหม่และค่าใช้จ่ายด้านสตอเรจเข้าไป
  • ชุมชน Git เฝ้าคิดเรื่องการแก้ปัญหารากฐานของไฟล์ขนาดใหญ่มาอย่างเงียบ ๆ และในรีลีสทางการล่าสุดของ Git ก็เริ่มเห็นทิศทางใหม่สำหรับการจัดการไฟล์ขนาดใหญ่โดยไม่ต้องพึ่ง LFS

วิธีที่ทำได้ตั้งแต่วันนี้: แทนที่ Git LFS ด้วย partial clone

  • หลักการของ partial clone

    • Git LFS: เก็บไฟล์ขนาดใหญ่ไว้นอกรีโพซิทอรี แล้วดาวน์โหลดเฉพาะไฟล์ที่ต้องใช้มาทำงาน
    • Git partial clone (เริ่มใช้ในปี 2017):
      • ใช้ออปชัน --filter เพื่อโคลนโดยตัด blob ที่มีขนาดเกินค่าที่ต้องการออก
      • ดาวน์โหลดไฟล์ขนาดใหญ่ที่เกี่ยวข้องจากเซิร์ฟเวอร์เมื่อจำเป็นเท่านั้น
        > เมื่อใช้ Partial clone คุณไม่จำเป็นต้องดาวน์โหลด [large binary assets] ล่วงหน้าระหว่าง Clone และ Fetch จึงช่วยลดเวลาในการดาวน์โหลดและการใช้พื้นที่ดิสก์ได้
        > - Partial Clone Design Notes, git-scm.com

  • จุดร่วมของ partial clone กับ LFS

    • 1. ลดขนาดตอน checkout ให้เล็กที่สุด: รับมาเฉพาะเวอร์ชันล่าสุดและละประวัติไฟล์ทั้งหมด
    • 2. โคลนได้เร็ว: เพราะไม่มีการส่งไฟล์ขนาดใหญ่ระหว่าง clone
    • 3. ตั้งค่าได้เร็ว: ต่างจาก shallow clone ตรงที่ยังเข้าถึงประวัติทั้งหมดของโปรเจกต์ได้

  • ตัวอย่างการใช้ partial clone

    • ตัวอย่างความเร็วในการโคลนและการใช้ดิสก์ของรีโพที่มีประวัติไฟล์ PNG ขนาดใหญ่จำนวนมาก:
      • โคลนแบบปกติใช้เวลาเกือบ 4 นาที และกินพื้นที่ 1.3GB
      • ถ้าใช้ partial clone และจำกัด blob ที่ 100KB จะโคลนเสร็จใน 6 วินาที และใช้พื้นที่ 49MB
      • เทียบกับต้นฉบับแล้ว ความเร็วในการโคลนดีขึ้น 97% และขนาดตอน checkout ลดลง 96%

  • ข้อจำกัดของ partial clone

    • หากต้องใช้ข้อมูลที่ถูกกรองออกไป (เช่น git diff, git blame, git checkout) Git จะร้องขอไฟล์จากเซิร์ฟเวอร์
    • นี่เป็นลักษณะเดียวกันกับ Git LFS
    • ในการทำงานจริง การไปใช้ blame กับไฟล์ไบนารีเกิดขึ้นไม่บ่อย

ปัญหาของ Git LFS

  • การผูกติดกับผู้ให้บริการสูง: อิมพลีเมนเทชันของ GitHub รองรับเฉพาะเซิร์ฟเวอร์ของตัวเอง ทำให้เกิดค่าใช้จ่ายและการผูกติด
  • ปัญหาเรื่องต้นทุน: เก็บ 50GB บน GitHub LFS มีค่าใช้จ่าย $40 ต่อปี ขณะที่ Amazon S3 อยู่ที่ $13
  • ย้อนกลับได้ยาก: เมื่อย้ายไปใช้ LFS แล้ว จะไม่สามารถกลับคืนสภาพเดิมได้หากไม่ rewrite history
  • ต้นทุนการตั้งค่าอย่างต่อเนื่อง: ผู้ร่วมงานทุกคนต้องติดตั้ง LFS หากไม่ติดตั้งจะเห็นเป็นไฟล์เมตาดาต้าแทนไฟล์จริง ซึ่งทำให้สับสน

แนวโน้มในอนาคต: Large Object Promisor

  • ไฟล์ขนาดใหญ่สร้างปัญหาเรื่องต้นทุนให้กับแพลตฟอร์มโฮสติ้งอย่าง GitHub และ GitLab เช่นกัน
  • Git LFS ช่วยลดต้นทุนเซิร์ฟเวอร์ด้วยการ offload ไฟล์ขนาดใหญ่ไปยัง CDN

  • Large Object Promisor คืออะไร

    • เมื่อต้นปีนี้ Git ได้ merge ฟีเจอร์ชื่อ large object promisor เข้ามาอย่างเป็นทางการ
    • ฟีเจอร์นี้ช่วยลดภาระสตอเรจฝั่งเซิร์ฟเวอร์คล้ายกับ LFS แต่ลดความซับซ้อนฝั่งผู้ใช้ลงได้มาก
      > ความพยายามนี้มีจุดมุ่งหมายเพื่อปรับปรุงงานฝั่งเซิร์ฟเวอร์ โดยเฉพาะงานที่เกี่ยวข้องกับ blob ขนาดใหญ่ซึ่งถูกบีบอัดในรูปแบบไบนารีอยู่แล้ว
      > เป็นโซลูชันที่ใช้แทน Git LFS ได้
      > – Large Object Promisors, git-scm.com

  • หลักการทำงาน

    • 1. ผู้ใช้ push ไฟล์ขนาดใหญ่ไปยัง Git host
    • 2. โฮสต์ทำการ offload ไฟล์ขนาดใหญ่ไปยัง promisor backend
    • 3. ตอน clone นั้น Git host จะให้ข้อมูล promisor แก่ไคลเอนต์
    • 4. ไคลเอนต์จะดึงไฟล์ขนาดใหญ่จาก promisor นั้นโดยอัตโนมัติเมื่อจำเป็น

  • สถานะการนำมาใช้และโจทย์ที่ยังเหลือ

    • promisor สำหรับไฟล์ขนาดใหญ่ยังอยู่ระหว่างการพัฒนา และมีบางส่วนของโค้ดถูก merge เข้า Git ในเดือนมีนาคม 2025
    • GitLab และที่อื่น ๆ กำลังคุยกันเรื่องการอิมพลีเมนต์เพิ่มเติมและประเด็นที่ยังไม่คลี่คลาย
    • กว่าจะมีการใช้งานอย่างแพร่หลายยังต้องใช้เวลาอีกพอสมควร
    • ในระยะสั้น การเก็บไฟล์ขนาดใหญ่ยังคงหลีกเลี่ยงการพึ่ง Git LFS ได้ยาก
    • หาก promisor ถูกใช้อย่างแพร่หลาย ก็มีแนวโน้มว่า GitHub จะสามารถอัปโหลดไฟล์ที่เกิน 100MB ได้ด้วย

สรุป: อนาคตของไฟล์ขนาดใหญ่ใน Git คือ Git

  • โปรเจกต์ Git ยังคงครุ่นคิดเรื่อง ปัญหาไฟล์ขนาดใหญ่ แทนทุกคนอย่างต่อเนื่อง
  • ตอนนี้ยังคงจำเป็นต้องใช้ Git LFS อยู่
  • แต่เมื่อ partial clone และ large object promisors พัฒนาต่อไป Git LFS จะค่อย ๆ หมดความจำเป็น และอีกไม่นานเราก็น่าจะเข้าสู่ยุคที่จัดการไฟล์ขนาดใหญ่ได้อย่างง่ายดายด้วย Git เพียงอย่างเดียว
  • ในอนาคต อุปสรรคสุดท้ายของการใช้งานไฟล์ขนาดใหญ่อาจเหลือแค่การตัดสินใจว่าจะใส่คลัง MP3 ลงใน Git หรือไม่เท่านั้น

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

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น