Git คืออะไร และนักพัฒนาต้องใช้เพื่ออะไร

Git คือระบบควบคุมเวอร์ชัน

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

หากเคยเก็บโฟลเดอร์ชื่อ "project_v2" "project_final" และ "project_final_REALLY_FINAL" คุณก็เคยทำการควบคุมเวอร์ชันมาแล้ว เพียงแต่ทำด้วยมือ Git ทำสิ่งเดียวกันโดยอัตโนมัติ กระชับ และไม่ต้องกลัวว่าจะทำอะไรหาย ดังนั้นเมื่อนักพัฒนาพูดว่า "git คืออะไร" ความหมายคือเครื่องมือทำงานพื้นฐาน ที่จำเป็นพอ ๆ กับเอดิเตอร์โค้ด ไม่ใช่แค่โปรแกรมหนึ่งตัว

Git ต่างจาก "โฟลเดอร์สำเนา" และคลาวด์ไดรฟ์อย่างไร

คลาวด์ไดรฟ์เก็บไฟล์เวอร์ชันล่าสุด และในกรณีที่ดีที่สุดคือสำเนาอัตโนมัติไม่กี่ชุด Git เก็บประวัติที่มีความหมาย คุณเป็นคนตัดสินใจเองว่าจะบันทึกการเปลี่ยนแปลงเมื่อไร และเขียนว่าทำอะไรไปบ้าง นอกจากนี้ Git ยังทำสิ่งที่ดิสก์ใดก็ทำไม่ได้:

• ดำเนินการพัฒนาหลายสายพร้อมกัน (บรานช์) และรวมเข้าด้วยกัน
• แสดงความต่างระหว่างเวอร์ชันทีละบรรทัด (git diff)
• รวมการแก้ไขของคนหลายคนในไฟล์เดียวกัน
• ค้นหาคอมมิตที่ทำให้เกิดข้อผิดพลาด (git bisect)
• ทำงานได้โดยไม่มีอินเทอร์เน็ต เพราะประวัติทั้งหมดอยู่ในเครื่องของคุณ

ความหมายของชื่อ Git

Git ไม่มีคำเต็มอย่างเป็นทางการ เพราะไม่ใช่ตัวย่อ Linus Torvalds ตั้งชื่อโปรแกรมตามสไตล์ของเขาเอง ในภาษาสแลงอังกฤษแบบอังกฤษ git หมายถึง "คนน่ารำคาญ ดื้อรั้น" ตัว Torvalds เองเคยพูดติดตลกว่าเขาตั้งชื่อโปรเจกต์ทั้งหมดตามตัวเอง คำแปลตรงตัวของ git คือประมาณ "คนเลว" หรือ "ไอ้งั่ง"

ใน README ฉบับแรกของโปรเจกต์ ผู้เขียนเสนอคำแปลชื่อแบบขำ ๆ หลายแบบ เช่น "global information tracker" เมื่อทุกอย่างทำงานได้ และคำด่าเมื่อระบบพัง ดังนั้นหากมีคนถามในการสัมภาษณ์งานว่า "git ย่อมาจากอะไร" คำตอบที่ถูกต้องคือไม่ได้ย่อมาจากอะไรเลย มันเป็นคำ ไม่ใช่อักษรย่อ

ในภาษาไทย คนมักเขียนและพูดว่า "Git" ออกเสียงว่า "กิต" ให้เน้นพยางค์เดียว ไม่ออกเสียงเป็น "จิต"

Git มาจากไหน

ก่อนปี 2005 นักพัฒนาเคอร์เนล Linux ใช้ระบบกรรมสิทธิ์ BitKeeper เมื่อใบอนุญาตฟรีสำหรับชุมชนถูกเพิกถอน Torvalds ใช้เวลาเพียงไม่กี่สัปดาห์ในการเขียนระบบของตัวเอง ข้อกำหนดนั้นเข้มงวด: ต้องเร็วในโปรเจกต์ขนาดใหญ่มาก ทำงานแบบกระจายโดยสมบูรณ์ ปกป้องประวัติจากการเสียหายได้อย่างมั่นคง และจัดการบรานช์นับพันที่ทำงานคู่ขนานได้อย่างสะดวก

ไม่นานหลังจากนั้น Junio Hamano รับหน้าที่ดูแลโปรเจกต์ และยังคงเป็นผู้ดูแลหลักของ Git จนถึงปัจจุบัน วันนี้ Git เป็นระบบโอเพนซอร์สภายใต้ใบอนุญาต GPLv2 และ GitHub, GitLab, Bitbucket, Gitea และแพลตฟอร์มระดับองค์กรหลายแห่งทำงานบนพื้นฐานของ Git

Git ทำงานอย่างไร: โครงสร้างภายใน

เพื่อให้ Git ไม่ดูเหมือนชุดคำสั่งลึกลับ ควรเข้าใจสามแนวคิด ซึ่งอธิบายพฤติกรรมของระบบได้เกือบทั้งหมด

1. สแนปชอต ไม่ใช่ผลต่าง

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

2. ทุกอย่างถูกระบุด้วยแฮช

อ็อบเจกต์ทุกชิ้นใน Git ได้แก่ เนื้อหาไฟล์ (blob) โครงสร้างโฟลเดอร์ (tree) และคอมมิต (commit) จะได้รับตัวระบุที่คำนวณจากเนื้อหาของมันเอง ในอดีตใช้ SHA-1 (40 ตัวอักษรเลขฐานสิบหก) และรุ่นใหม่สามารถสร้างรีโพซิทอรีด้วย SHA-256 ได้ การแก้ไขคอมมิตเก่าโดยไม่ให้ใครรู้ทำไม่ได้ เพราะแฮชจะเปลี่ยน และแฮชของทุกคอมมิตหลังจากนั้นจะเปลี่ยนตาม

$ git log --oneline -3
a3f9c21 เพิ่มฟอร์มเข้าสู่ระบบ
7b02e4d แก้การตรวจสอบอีเมล
1c8d5f0 คอมมิตแรก

ตัวอักษรสั้น ๆ ทางซ้ายคือแฮชย่อของคอมมิต ใช้อ้างถึงเวอร์ชันใดก็ได้ เช่น git show 7b02e4d

3. สามสถานะของไฟล์

นี่คือพื้นฐานที่สุดของ Git ซึ่งมักถูกถามเกือบทุกการสัมภาษณ์งาน ไฟล์ในโปรเจกต์อยู่ได้ในหนึ่งในสามโซน:

ดัชนีคือสิ่งที่แยก Git ออกจากระบบอื่นหลายระบบ มันช่วยให้คุณรวมเฉพาะบางส่วนของการเปลี่ยนแปลงเป็นคอมมิตได้ เช่น แก้บั๊กในคอมมิตหนึ่ง และเปลี่ยนชื่อตัวแปรในอีกคอมมิตหนึ่ง ทำให้ประวัติอ่านง่าย

การกระจาย: ทำไมทุกคนมีสำเนาเต็ม

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

เซิร์ฟเวอร์อย่าง GitHub ในโมเดลนี้เป็นเพียงสำเนาอีกชุดของรีโพซิทอรี ที่ทีมตกลงกันให้เป็นชุดหลัก หากเซิร์ฟเวอร์ใช้งานไม่ได้ งานก็ยังไม่หยุด คุณยังคอมมิตต่อได้ และส่งการเปลี่ยนแปลงในภายหลังด้วย git push หากเซิร์ฟเวอร์สูญหายไปจริง ก็กู้ประวัติกลับมาได้จากโคลนใดก็ได้

Git กับ GitHub ไม่ใช่สิ่งเดียวกัน

ความสับสนที่พบบ่อยในหมู่ผู้เริ่มต้น Git คือโปรแกรมที่ทำงานบนคอมพิวเตอร์ของคุณ ส่วน GitHub คือบริการเว็บที่เก็บรีโพซิทอรี Git และมีเครื่องมือสำหรับการทำงานเป็นทีม ได้แก่ pull request การรีวิวโค้ด งาน และ CI GitLab และ Bitbucket เป็นบริการที่คล้ายกัน

คุณสามารถใช้ Git โดยไม่ต้องใช้ GitHub ได้ เช่นสำหรับโน้ตส่วนตัวหรือโปรเจกต์ในเครื่อง แต่ GitHub โดยไม่มี Git ไม่มีความหมาย เพราะมันสร้างขึ้นรอบ ๆ รีโพซิทอรีของ Git

พื้นฐานของ Git: วงจรการทำงานขั้นต่ำ

นี่คือหน้าตาของการทำงานประจำวัน คำสั่งไม่กี่คำสั่งนี้ครอบคลุมสิ่งที่นักพัฒนาทำทุกวันส่วนใหญ่

# สร้างรีโพซิทอรีในโฟลเดอร์ปัจจุบัน
git init

# ดูว่ามีอะไรเปลี่ยนแปลงไปบ้าง
git status

# เพิ่มไฟล์เข้าดัชนี
git add index.html style.css

# บันทึกสแนปชอต
git commit -m "จัดหน้าแรก"

# ดูประวัติ
git log --oneline

# สร้างบรานช์และสลับไปยังบรานช์นั้น
git switch -c feature/login

# รวมบรานช์เข้าสู่บรานช์หลัก
git switch main
git merge feature/login

# ส่งการเปลี่ยนแปลงขึ้นเซิร์ฟเวอร์
git push origin main

คำสั่ง git switch ถูกเพิ่มใน Git 2.23 เป็นทางเลือกที่เข้าใจง่ายกว่าสำหรับบางหน้าที่ของ git checkout ในคู่มือเก่าคุณจะพบ git checkout -b feature/login ซึ่งทำงานเหมือนกัน

เกิดอะไรขึ้นเมื่อรัน git commit

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

เหตุผลเชิงปฏิบัติที่นักพัฒนาควรใช้ Git

ทดลองได้โดยไม่ต้องกลัว

ทุกการเปลี่ยนแปลงย้อนกลับได้ หากโค้ดพัง git restore ไฟล์ จะคืนเวอร์ชันที่คอมมิตล่าสุด หากคอมมิตที่ไม่ดีอยู่ในประวัติแล้ว git revert จะสร้างคอมมิตย้อนกลับโดยไม่เขียนประวัติร่วมใหม่ สิ่งนี้เปลี่ยนรูปแบบการทำงาน คุณจะกล้าลองมากขึ้น เพราะการย้อนกลับใช้เวลาเพียงไม่กี่วินาที

ทำงานเป็นทีมโดยไม่วุ่นวาย

นักพัฒนาแต่ละคนทำงานในบรานช์ของตัวเองโดยไม่รบกวนคนอื่น เมื่องานเสร็จ การเปลี่ยนแปลงจะผ่านการรีวิวและถูกรวมเข้าบรานช์หลัก หากคนสองคนแก้โค้ดส่วนเดียวกัน Git จะแสดงความขัดแย้ง และให้คุณแก้ไขอย่างตั้งใจ แทนที่จะเขียนทับงานของคนอื่นโดยเงียบ ๆ

ประวัติคือเอกสาร

ข้อความคอมมิตที่ดีตอบคำถามว่า "ทำไมโค้ดถึงเป็นแบบนี้" คำสั่ง git blame ไฟล์ จะแสดงว่าใครและในคอมมิตใดแก้แต่ละบรรทัดล่าสุด ส่วน git log -p ไฟล์ แสดงการพัฒนาทั้งหมดของไฟล์ สิ่งนี้ช่วยประหยัดเวลาในการสืบค้นได้หลายชั่วโมงในหนึ่งปีถัดมา

นายจ้างต้องการ

ความรู้ Git ถูกระบุในประกาศงานแทบทุกตำแหน่ง ทั้งนักพัฒนา ผู้ทดสอบ วิศวกร DevOps และนักวิเคราะห์ข้อมูล ในการสัมภาษณ์ สิ่งที่ตรวจสอบไม่ใช่การท่องคำสั่ง แต่เป็นความเข้าใจ เช่น merge ต่างจาก rebase อย่างไร ดัชนีคืออะไร จะยกเลิกคอมมิตอย่างไร และจะแก้ความขัดแย้งอย่างไร และโปรไฟล์ GitHub ที่มีประวัติคอมมิตเป็นระเบียบทำหน้าที่เหมือนพอร์ตโฟลิโอ

ใครอื่นควรใช้ Git

Git เป็นประโยชน์ทุกที่ที่มีไฟล์ข้อความและประวัติมีความสำคัญ เช่น นักเขียนเทคนิค (เอกสารใน Markdown) นักออกแบบเว็บ นักวิเคราะห์ (สคริปต์ SQL โน้ตบุ๊ก) ผู้ดูแลระบบ (คอนฟิกเซิร์ฟเวอร์ โครงสร้างพื้นฐานเป็นโค้ด) สำหรับไฟล์ไบนารีขนาดใหญ่ เช่น วิดีโอ PSD หรือชุดข้อมูล มักใช้ส่วนขยาย Git LFS เพราะตัว Git เองถูกปรับให้เหมาะกับข้อความ

Pro Git หนังสือที่ดีที่สุดเกี่ยวกับ Git

หากต้องการเจาะลึก เริ่มจากหนังสือ "Pro Git" ของ Scott Chacon และ Ben Straub หนังสือนี้ให้อ่านฟรี เผยแพร่ภายใต้ใบอนุญาตโอเพนซอร์ส และเผยแพร่บนเว็บไซต์ทางการ git-scm.com ในส่วน Book โดยมีฉบับแปลหลายภาษา นี่คือ "git pro" ที่คนมักค้นหา คือตำราฉบับสมบูรณ์ตั้งแต่พื้นฐานจนถึงโครงสร้างภายใน

วิธีอ่านให้ได้ประโยชน์:

• บทที่ 1–3 (บทนำ พื้นฐาน การแตกบรานช์) คือขั้นต่ำที่จำเป็น ให้ทวนคำสั่งในเทอร์มินัลไปด้วย
• บทเกี่ยวกับการทำงานกับรีโมตรีโพซิทอรีและ GitHub เมื่อเริ่มทำงานเป็นทีม
• บท "Git ภายใน" เมื่อต้องการเข้าใจจริงว่าอ็อบเจกต์และการอ้างอิงทำงานอย่างไร

แหล่งอ้างอิงทางการอีกแห่งคือความช่วยเหลือในตัว git help commit หรือ git commit --help จะเปิดเอกสารฉบับเต็มของคำสั่ง ส่วน git commit -h แสดงสรุปแฟล็กแบบย่อ

ความเข้าใจผิดที่พบบ่อยของผู้เริ่มต้น

• "Git บันทึกไฟล์ให้อัตโนมัติ" ไม่ใช่ จนกว่าคุณจะคอมมิต การเปลี่ยนแปลงมีอยู่เฉพาะในไดเรกทอรีทำงาน
• "คอมมิตขึ้น GitHub ทันที" ไม่ใช่ คอมมิตเป็นของเครื่องคุณ จะถูกส่งขึ้นเซิร์ฟเวอร์ก็ต่อเมื่อรัน git push
• "git add ใช้กับไฟล์ใหม่เท่านั้น" ไม่ใช่ git add เพิ่มเข้าดัชนีได้ทั้งไฟล์ใหม่และการแก้ไขของไฟล์ที่ถูกติดตามอยู่แล้ว
• "สิ่งที่ลบออกจากประวัติกู้คืนไม่ได้" เกือบทุกครั้งกู้คืนได้ git reflog เก็บการเคลื่อนที่ของพอยน์เตอร์ และคอมมิตที่ "หายไป" หาเจอได้ด้วยแฮช
• "บรานช์คือสำเนาของโปรเจกต์" ไม่ใช่ บรานช์คือพอยน์เตอร์น้ำหนักเบาไปยังคอมมิต ไม่ใช่สำเนาของไฟล์

เริ่มเรียนรู้จากตรงไหน

1. ติดตั้ง Git และตรวจสอบเวอร์ชัน: git --version
2. ตั้งชื่อและอีเมล: git config --global user.name และ user.email
3. สร้างรีโพซิทอรีสำหรับฝึก ทำคอมมิตสัก 5–10 ครั้ง แล้วดู git log และ git diff
4. ฝึกกับบรานช์: สร้าง merge และตั้งใจสร้างความขัดแย้งแล้วแก้ไข
5. สร้างบัญชี GitHub ส่งรีโพซิทอรีขึ้นไป และเปิด pull request แรกของคุณ

ลำดับนี้ให้ผลเร็วกว่าการอ่านคู่มืออ้างอิงไล่ไปเรื่อย ๆ เพราะคุณจะเห็นทันทีว่าแต่ละคำสั่งเปลี่ยนสถานะของรีโพซิทอรีอย่างไร

สรุป

Git คือระบบควบคุมเวอร์ชันแบบกระจาย ที่เก็บประวัติโปรเจกต์เป็นสแนปชอต ปกป้องด้วยแฮช และให้ทีมทำงานคู่ขนานในบรานช์ได้ ชื่อ Git ไม่ได้ย่อมาจากอะไร แต่ "git คืออะไร" ในทางปฏิบัติหมายถึงเครื่องมือพื้นฐานที่นักพัฒนาทุกคนต้องมี เริ่มจากฝึกวงจร add — commit — push เข้าใจสามโซนของไฟล์และบรานช์ แล้วค่อยเจาะลึกด้วยหนังสือ Pro Git ทั้งหมดนี้ทีละขั้น ตั้งแต่คอมมิตแรกจนถึง pull request ถูกอธิบายและฝึกจริงในหลักสูตร Git