ย้อนมอง 20 ปีของ Git – ยังประหลาดอยู่เสมอ และยังเป็นเครื่องมือที่ยอดเยี่ยม

• Git คือระบบควบคุมเวอร์ชันที่เริ่มต้นขึ้นเมื่อ 20 ปีก่อน จากคอมมิตแรกของ Linus Torvalds
• เดิมทีเป็นเพียงโปรเจกต์ส่วนตัวเล็ก ๆ แต่ต่อมาก็เติบโตเป็นระบบควบคุมเวอร์ชันที่ถูกใช้งานแพร่หลายที่สุดในโลก
• ผู้เขียนเป็นผู้ร่วมก่อตั้ง GitHub และมีส่วนเกี่ยวข้องอย่างลึกซึ้งกับพัฒนาการของ Git ผ่านการสร้างหนังสือและคอมมูนิตี้เกี่ยวกับ Git
• ในช่วงแรกมันเป็นเพียงเครื่องมือจัดการเนื้อหาของไดเรกทอรีแบบง่าย ๆ แต่ตอนนี้ได้กลายเป็นเครื่องมือหลักที่เปลี่ยนวิธีการพัฒนาซอฟต์แวร์ไปแล้ว

ปรัชญาและความจำเป็นของ Git

• Git ถือกำเนิดขึ้นจากความไม่พอใจของคอมมูนิตี้ Linux kernel ต่อข้อจำกัดของเครื่องมือควบคุมเวอร์ชันที่มีอยู่เดิม
• วิธีทำงานร่วมกันในยุคนั้นอาศัย mailing list, tarball และไฟล์ patch ในรูปแบบการทำงานร่วมกันแบบกระจายตัวและอิงตามพื้นที่
• เครื่องมือ SCM ในเวลานั้นทั้งช้า รวมศูนย์ และไม่มีประสิทธิภาพ จนแนวทางแบบ tarball/patch กลับใช้งานได้ดีกว่า
• มีเครื่องมือทางเลือกชื่อ Bitkeeper แต่ปัญหาเรื่องไลเซนส์ทำให้การพัฒนา Git เริ่มต้นขึ้น
• Git ไม่ได้ถูกออกแบบมาให้เป็น "ระบบควบคุมเวอร์ชัน" ตั้งแต่แรก แต่ถูกออกแบบเป็นโครงสร้างข้อมูลเพื่อจัดการ patch และ tarball ให้ดีขึ้น

คอมมิตแรกของ Git

• คอมมิตแรกเป็นเครื่องมือติดตามเนื้อหาในไดเรกทอรีที่พื้นฐานมาก
• เครื่องมือในตอนนั้นยังไม่ใช่คำสั่งอย่าง git commit แต่เป็นเครื่องมือฐานข้อมูลระดับล่างอย่าง write-tree, commit-tree เป็นต้น
• Git มีความสามารถต่อไปนี้ตั้งแต่แรกเริ่ม:
  • บันทึก working directory ลงในแคช (update-cache) แล้วทำให้เป็นอ็อบเจ็กต์แบบ tree (write-tree) เพื่อเขียนลงฐานข้อมูล
  • บันทึกการเปลี่ยนแปลงเป็นคอมมิต (commit-tree) เพื่อสร้างประวัติ
  • อ่านและเปรียบเทียบอ็อบเจ็กต์ในฐานข้อมูลด้วย cat-file, read-tree, show-diff
• Linus มอง Git เป็นเพียง backend "เครื่องมือท่อประปา(plumbing)" และต้องการให้มีการสร้าง UI จากภายนอก

กรณีศึกษา: การกระจายคอนเทนต์ด้วย Git

• ผู้เขียนใช้ Git ในปี 2005 ที่สตาร์ตอัปชื่อ Reactrix เพื่อกระจายคอนเทนต์โฆษณาดิจิทัล
• จอดิจิทัลหลายร้อยจอจำเป็นต้องมีชุดโฆษณาที่แตกต่างกัน และความสามารถด้าน content-addressing ของ Git ก็ช่วยแก้ปัญหานี้ได้อย่างมีประสิทธิภาพ
• นี่เป็นตัวอย่างที่สร้างสรรค์ของการใช้ Git ไม่ใช่เพื่อจัดการโค้ด แต่เพื่อกระจายคอนเทนต์
• Nick Hengeveld ซึ่งเป็นหนึ่งในผู้มีส่วนร่วมหลักของโปรเจกต์ Git ยุคแรก ได้เพิ่มความสามารถอย่าง SSL และการส่งผ่าน HTTP แบบขนาน
• ประสบการณ์นี้กลายเป็นจุดเริ่มต้นที่ทำให้เกิดเอกสาร เว็บไซต์ และหนังสือเกี่ยวกับ Git และนำไปสู่ GitHub ในที่สุด

วิวัฒนาการของคำสั่ง Git และเครื่องมือสำหรับผู้ใช้

• คำสั่ง Git ยุคแรกทั้งหมดเป็นเครื่องมือระดับล่างที่อิงสคริปต์ ซึ่งแตกต่างจากปัจจุบันมาก
• คำสั่งอย่าง git log, git rebase, git commit เองก็เริ่มจากเชลล์สคริปต์ง่าย ๆ ก่อนจะค่อย ๆ พัฒนาเป็นรูปแบบที่ใช้อยู่ในปัจจุบัน

เวอร์ชันแรกของ git log

• git log เป็นสคริปต์ง่าย ๆ ในรูปแบบ git-rev-list --pretty HEAD | less
• rev-list เป็นเครื่องมือสำหรับแสดง commit ID ที่ยังคงมีอยู่จนถึงปัจจุบัน

การถือกำเนิดของ git rebase

• แนวคิดของ rebase เกิดขึ้นจากอีเมลสนทนาระหว่าง Linus และ Junio Hamano ในปี 2005
• วิธีทำงานของ Junio คือทิ้ง HEAD เดิม แล้วทำงานต่อโดยอิงกับ HEAD ใหม่ ซึ่งเขาเรียกมันว่า "rebase"
• สิ่งนี้ต่อมาได้พัฒนาเป็นคำสั่ง git rebase ที่เรารู้จักในปัจจุบัน

ที่มาของ Octocat

• Octocat ซึ่งเป็นสัญลักษณ์ของ GitHub ได้ไอเดียมาจากกลยุทธ์ "octopus merge" ใน Git
• กลยุทธ์ที่รวมหลาย branch พร้อมกันถูกเรียกว่า "octopus" และในยุคแรกของ GitHub คำนี้ก็เป็นแรงบันดาลใจให้เกิดตัวละคร Octocat

ปัจจุบันและอนาคตของ Git

• ผู้เขียนยังคงใช้ Git ตามเป้าหมายดั้งเดิมในฐานะ "stupid content tracker"
• โปรเจกต์ GitButler กำลังใช้ Git เพื่อติดตามและบันทึกประวัติของโปรเจกต์
• Git ยังคงเป็นระบบติดตามคอนเทนต์และระบบแบบกระจายศูนย์ที่ทรงพลัง และในอนาคตก็ยังมีศักยภาพที่จะถูกนำไปใช้ได้อีกหลากหลายรูปแบบ

• สุขสันต์วันเกิดนะ Git ยังประหลาดอยู่เสมอ และยังเป็นเครื่องมือที่ยอดเยี่ยม

[aobamisaki]

สุขสันต์วันเกิดครบรอบ 20 ปีของ Git

[bobross0]

ยินดีด้วย

[girr311]

สุขสันต์วันเกิดนะ เชื่อฟังคุณลุงแล้วก็ขอให้สุขภาพแข็งแรงไปนานๆ

[kaistj]

สุขสันต์วันเกิด ^^

[crawler]

เป็นโพสต์ที่ชวนให้ฮึกเหิมขึ้นมาอย่างประหลาดเลยนะเนี่ย

[GN⁺]

ความคิดเห็นจาก Hacker News

• เรื่องราวเกี่ยวกับจุดกำเนิดของ Git มักมีแนวโน้มจะพรรณนา Linus ราวกับเป็นศาสดา

  • โพสต์บล็อกนี้เน้นด้านความเป็นมนุษย์ของ Linus และกล่าวถึงการลองผิดลองถูกในช่วงแรก
  • Mercurial ก็มีบทบาทสำคัญเช่นกัน แต่ก็มักถูกมองข้าม
  • Mercurial มี UI มาตั้งแต่แรก และเป็นมิตรต่อผู้ใช้ด้วย UI ที่คล้ายกับ Subversion
  • โครงสร้างข้อมูลของ Git ไม่เหมาะกับไฟล์ขนาดใหญ่
  • ไม่คิดว่า Git เป็นสิ่งที่หลีกเลี่ยงไม่ได้ และหวังว่าจะมีทางเลือกใหม่ ๆ ออกมา

• ราวปี 2002 เคยมีไอเดียที่จะติดแท็กแต่ละส่วนของโปรเจ็กต์ด้วยแฮชโค้ดที่ไม่ซ้ำกัน

  • เคยเสนอให้บริษัทซอฟต์แวร์แห่งหนึ่ง แต่ไม่ได้รับความสนใจ

• เริ่มใช้ Git เป็นทางเลือกแทน ClearCase

  • เริ่มใช้ Git ราวปี 2007 และเขียนสคริปต์เพื่อแก้ปัญหาความไม่สะดวกของ ClearCase
  • ในปี 2008 เริ่มส่งแพตช์ให้ Git และได้เรียนรู้อะไรมากมายเกี่ยวกับการมีส่วนร่วมในโอเพนซอร์ส
  • แม้ CLI ของ Git จะซับซ้อน แต่ก็ไม่ได้มีปัญหาในการใช้งาน
  • ในงานถัดไป ได้ทำงานบนฐานของ Chromium fork และใช้ Git จนชำนาญในการแก้ merge conflict
  • รู้สึกผิดหวังที่ GitHub กลายเป็นเครื่องมือ code review หลักของ Git แต่ก็คิดว่า Git เป็นตัวเลือกที่ดีกว่า Mercurial

• น่าประหลาดใจที่ Git มีอายุเพียง 20 ปีเท่านั้น

  • การที่ GitHub มีอายุไม่ถึง 20 ปีนั้นไม่น่าแปลกใจ แต่การที่ Git ไม่มีอยู่ก่อนปี 2005 นั้นชวนช็อก
  • ไม่เคยใช้ตัวเลือก source control อื่นมาก่อน และก็สงสัยว่าในอนาคตจะได้ใช้หรือไม่

• น่าสนใจที่ได้รู้บริบททางประวัติศาสตร์

  • ClearCase ก็ใช้คำว่า "rebase" เช่นกัน และตรวจสอบได้ว่าใช้มาตั้งแต่ปี 1999
  • rebase ของ ClearCase ใช้เวลานานมาก แต่ rebase ที่แทบจะทันทีของ Git นั้นน่าทึ่ง

• ต้องการสร้างเครื่องมือฐานข้อมูลประวัติ tarball ที่มีประสิทธิภาพ ไม่ได้ตั้งใจจะสร้างระบบควบคุมเวอร์ชัน

• เพิ่งรู้ว่าสามารถเซ็น commit ด้วย ssh key ได้

  • ใช้วิธีเซ็นด้วย ssh เพื่อแก้ปัญหาบน OpenBSD
  • ไม่น่าเชื่อเลยว่าผ่านมา 20 ปีแล้วตั้งแต่ย้ายรายการงานจาก CVS มา Git

• ขอบคุณสำหรับบทความที่เป็นประโยชน์ และขอแนะนำรีโพซิทอรีที่มีบทนำเกี่ยวกับโครงสร้างภายในของ Git

• ความเห็นที่ว่าอยากเขียนโพสต์บล็อกเกี่ยวกับการทำงานร่วมกันผ่าน mailing list นั้นน่าสนใจ

• ในบรรดาระบบ source control หลายตัว Git ใช้งานได้แย่ที่สุด แต่ก็เป็นระบบที่ชอบที่สุด