Git — คืออะไร หลักการทำงานและคำสั่ง

Git คืออะไร?

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

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

ตามผลสำรวจของ Stack Overflow (2024) นักพัฒนามืออาชีพ 93.9% ใช้ Git ทำให้เป็นระบบควบคุมเวอร์ชันที่โดดเด่นในอุตสาหกรรม คู่แข่งที่ใกล้เคียงที่สุด — Subversion (SVN) — ใช้ในเพียง 5.2% ของโครงการ โดยหลักในสภาพแวดล้อมองค์กรขนาดใหญ่ที่มีกระบวนการแบบรวมศูนย์

Git ทำงานอย่างไร: คลังข้อมูลและคอมมิต

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

แต่ละ คอมมิต ประกอบด้วย: แฮช SHA-1 ที่ไม่ซ้ำกัน (40 ตัวอักษร) การอ้างอิงถึงคอมมิตก่อนหน้า (parent) ผู้เขียน วันที่ ข้อความคอมมิต และการอ้างอิงถึงต้นไม้ที่อธิบายสถานะของไฟล์ ณ เวลาที่คอมมิต ห่วงโซ่ของคอมมิตก่อให้เกิดกราฟแบบมีทิศทางไม่มีวัฏจักร โดยแต่ละคอมมิตชี้ไปที่ผู้ปกครองหนึ่งคนหรือมากกว่า

# การเริ่มต้นคลังข้อมูล
git init my-project
cd my-project

# การสร้างคอมมิต
echo "สวัสดี Git" > README.md
git add README.md
git commit -m "Initial commit"

# การดูประวัติ
git log --oneline --graph --all

Git ใช้สามพื้นที่หลัก: working directory (ไฟล์บนดิสก์), staging area (ดัชนีที่ไฟล์ที่เตรียมแล้วไป) และ repository (ประวัติคอมมิต) คำสั่ง git add ย้ายการเปลี่ยนแปลงจากไดเรกทอรีทำงานไปยัง staging และ git commit บันทึกเนื้อหาของ staging ลงในคลังข้อมูล การแยกนี้ช่วยให้นักพัฒนาประกอบคอมมิตที่มีความหมายจากชุดการเปลี่ยนแปลงโดยไม่ต้องคอมมิตแต่ละการแก้ไขแยกกัน

คำสั่ง Git พื้นฐาน

คำสั่ง Git พื้นฐาน ครอบคลุม 90% ของการดำเนินงานประจำวันของนักพัฒนา คำสั่ง git clone สร้างสำเนาท้องถิ่นของคลังข้อมูลระยะไกล git pull ดึงการเปลี่ยนแปลงจากเซิร์ฟเวอร์และรวมเข้ากับสาขาปัจจุบัน และ git push ส่งคอมมิตท้องถิ่นไปยังเซิร์ฟเวอร์ สามคำสั่งนี้ก่อให้เกิดวงจรหลักของการทำงานกับ Git

ในการดูสถานะ ใช้ git status — มันแสดงไฟล์ที่ถูกแก้ไข ไฟล์ที่ถูกเพิ่มไปยัง staging และไฟล์ที่ไม่ได้ถูกติดตาม git diff แสดงการเปลี่ยนแปลงเฉพาะในไฟล์ก่อนเพิ่มไปยัง staging ด้านล่างคือตารางคำสั่งที่ใช้บ่อยที่สุด:

ในการยกเลิกการเปลี่ยนแปลง Git มีตัวเลือกหลายอย่าง git reset ย้ายตัวชี้สาขาไปยังคอมมิตที่ระบุและสามารถรีเซต staging หรือไดเรกทอรีทำงาน git revert สร้างคอมมิตใหม่ที่ย้อนกลับการเปลี่ยนแปลงของคอมมิตที่ระบุ — นี่เป็นวิธีที่ปลอดภัยในการยกเลิกสำหรับสาขาที่ใช้ร่วมกันเนื่องจาก ประวัติ ไม่ถูกเขียนทับ

การแตกสาขาใน Git: main, feature และ release

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

แนวทางปฏิบัติมาตรฐานคือการใช้ Git Flow หรือ GitHub Flow Git Flow ใช้สาขา: main (โค้ดเผยแพร่), develop (สาขาการรวม), feature/* (ฟีเจอร์ใหม่), release/* (การเตรียมเผยแพร่) และ hotfix/* (การแก้ไขด่วน) GitHub Flow ง่ายกว่า: มีเพียง main และสาขาฟีเจอร์ และการเปลี่ยนแปลงทั้งหมดถูกส่งผ่าน Pull Request

# การสร้างและเปลี่ยนสาขา
git branch feature-auth
git checkout feature-auth
# หรือด้วยคำสั่งเดียว:
git checkout -b feature-auth

# รายการสาขา
git branch --list
git branch -a  # ทุกสาขา รวมถึงสาขาที่ถูกลบ

# การลบสาขา
git branch -d feature-auth

คุณสมบัติที่สำคัญของ การแตกสาขาใน Git คือ cherry-pick: การย้ายคอมมิตแต่ละรายการจากสาขาหนึ่งไปยังอีกสาขาหนึ่งโดยใช้คำสั่ง git cherry-pick <hash> สิ่งนี้มีประโยชน์เมื่อคุณต้องการย้ายการแก้ไขบั๊กจากสาขาฟีเจอร์ไปยังรุ่นเผยแพร่โดยไม่ต้องรวมทั้งสาขา Git ยังรองรับการรีเบสและการรีเบสแบบโต้ตอบ (git rebase -i) สำหรับการรวม จัดลำดับใหม่ และแก้ไขคอมมิต

Merge และ Rebase

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

Rebase (การรีเบส) แทนที่จะสร้างคอมมิตการรวม จะย้ายคอมมิตของสาขาปัจจุบันไปยังปลายของสาขาเป้าหมาย ประวัติกลายเป็นเส้นตรง — สร้างความประทับใจว่าการพัฒนาเป็นลำดับ อย่างไรก็ตาม รีเบสเขียนประวัติใหม่ เปลี่ยนแฮช SHA-1 ของคอมมิต ทำให้มัน อันตราย สำหรับสาขาที่ใช้ร่วมกันซึ่งนักพัฒนาคนอื่นสามารถเข้าถึงได้

คำแนะนำ: ใช้ merge สำหรับสาธารณะที่ประวัติปรากฏแก่นักพัฒนาคนอื่น (feature → develop) และ rebase สำหรับงานท้องถิ่นเมื่อคุณต้องการใช้การเปลี่ยนแปลงล่าสุดจาก main ไปยังสาขาฟีเจอร์ของคุณก่อนสร้าง Pull Request กฎง่ายๆ: หากคอมมิตถูกส่งไปยังเซิร์ฟเวอร์แล้ว — อย่ารีเบสมัน

การแก้ไขความขัดแย้ง

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

การทำงานกับคลังข้อมูลระยะไกล

คลังข้อมูลระยะไกล (remote) คือสำเนาของคลังข้อมูล Git ที่อยู่บนเซิร์ฟเวอร์ GitHub, GitLab และ Bitbucket เป็นแพลตฟอร์มที่นิยมมากที่สุดสำหรับโฮสต์คลังข้อมูลระยะไกล พวกมันให้อินเทอร์เฟซเว็บสำหรับดูโค้ด จัดการการเข้าถึง ตรวจสอบโค้ด และรวมเข้ากับระบบ CI/CD

ใน Git คุณสามารถกำหนดค่าคลังข้อมูลระยะไกลหลายแห่งสำหรับหนึ่งโครงการ โดยค่าเริ่มต้น ระยะไกลหลักเรียกว่า origin คำสั่ง git remote add เพิ่มระยะไกลใหม่ git fetch ดึงการเปลี่ยนแปลงโดยไม่รวม และ git pull เป็นตัวย่อสำหรับ git fetch + git merge ในการทำงานกับโค้ดผ่าน Pull Request นักพัฒนาสร้างฟอร์กของคลังข้อมูล โคลนมัน ทำงานในสาขาฟีเจอร์ และส่งคำขอรวมไปยังคลังข้อมูลต้นฉบับ

# การเพิ่มคลังข้อมูลระยะไกล
git remote add origin https://github.com/user/repo.git

# การดูคลังข้อมูลระยะไกล
git remote -v

# การส่งสาขาไปยังเซิร์ฟเวอร์
git push -u origin feature-auth

# การดึงการเปลี่ยนแปลงจากสาขาระยะไกล
git pull origin main

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

Git Worktree สำหรับการทำงานแบบขนาน

Git Worktree ช่วยให้คุณทำงานกับหลายสาขาพร้อมกันในไดเรกทอรีต่างๆ โดยไม่ต้องสลับระหว่างมัน คำสั่ง git worktree add ../feature-auth feature-auth สร้างไดเรกทอรีทำงานใหม่ feature-auth ที่คุณสามารถเขียนโค้ดได้โดยไม่ต้องเปลี่ยนสาขาในไดเรกทอรีหลัก Worktree มีประโยชน์สำหรับการแก้ไขด่วนในสาขาเผยแพร่เมื่อไดเรกทอรีหลักกำลังยุ่งกับการพัฒนาระยะยาว

Git Submodules สำหรับการพึ่งพา

Git Submodules เป็นกลไกสำหรับรวมคลังข้อมูล Git หนึ่งไว้ภายในอีกแห่ง Submodule เก็บการอ้างอิงไปยังคอมมิตที่คงที่ของคลังข้อมูลภายนอก เพื่อให้แน่ใจถึงความสามารถในการทำซ้ำของการ build คำสั่ง git submodule add https://github.com/example/lib.git เพิ่มไลบรารีภายนอกเป็นซับโมดูล เมื่อโคลนโครงการที่มีซับโมดูล จำเป็นต้องเรียกใช้ git submodule update --init --recursive เพื่อดาวน์โหลดการพึ่งพาทั้งหมด