คำถามและคำตอบสัมภาษณ์ GIT 50 อันดับแรก (2026)
ลูคัส เบนเน็ตต์
เตรียมตัวสัมภาษณ์งาน GIT หรือยัง? ถึงเวลาสำรวจคำถามสำคัญที่จะทดสอบความเชี่ยวชาญด้านการควบคุมเวอร์ชันของคุณ ทำความเข้าใจ คำถามสัมภาษณ์ GIT ช่วยเผยให้เห็นความลึกซึ้งในการแก้ปัญหา นิสัยการทำงานร่วมกัน และประสิทธิภาพในการจัดการเวิร์กโฟลว์
อาชีพด้านการควบคุมเวอร์ชันและการทำงานร่วมกันมอบโอกาสมากมายให้กับผู้เชี่ยวชาญที่มีประสบการณ์ทางเทคนิคที่แข็งแกร่งและความเชี่ยวชาญเฉพาะด้าน ตั้งแต่วิศวกรมือใหม่ไปจนถึงวิศวกรอาวุโส การเข้าใจแนวคิดทั่วไปและแนวคิดขั้นสูงจะช่วยให้ผ่านช่วงคำถามและคำตอบที่ท้าทายได้ การทำงานภาคสนามช่วยพัฒนาทักษะการวิเคราะห์ การทำงานเป็นทีม และความเชี่ยวชาญทางเทคนิคเชิงปฏิบัติ ซึ่งเป็นสิ่งที่ผู้จัดการและหัวหน้าทีมให้ความสำคัญ
คู่มือนี้รวบรวมมุมมองการสัมภาษณ์ GIT ชั้นนำจากหลากหลายอุตสาหกรรม โดยอิงตามข้อมูลเชิงลึกจากผู้เชี่ยวชาญกว่า 75 ราย รวมถึงผู้นำทางเทคนิค ผู้จัดการ และนักพัฒนา เพื่อสร้างความน่าเชื่อถือ ความแม่นยำในทางปฏิบัติ และครอบคลุมอย่างครอบคลุมสำหรับทุกระดับประสบการณ์
คำถามและคำตอบสัมภาษณ์ GIT 50 อันดับแรก
1) Git คืออะไร และแตกต่างจากระบบควบคุมเวอร์ชันอื่นอย่างไร
Git คือระบบควบคุมเวอร์ชันแบบกระจายที่ออกแบบมาเพื่อติดตามการเปลี่ยนแปลงในซอร์สโค้ดระหว่างการพัฒนาซอฟต์แวร์ ต่างจากระบบรวมศูนย์อย่าง SVN หรือ CVS ตรงที่ Git ช่วยให้นักพัฒนาทุกคนมีสำเนาของรีพอริตี้ทั้งหมด รวมถึงประวัติทั้งหมด รูปแบบการกระจายศูนย์นี้ช่วยเพิ่มความเร็ว ความยืดหยุ่น และความน่าเชื่อถือ
ตัวอย่าง: เมื่อคุณโคลนที่เก็บข้อมูล Git คุณสามารถทำงานแบบออฟไลน์และคอมมิตในเครื่องได้ ซึ่งแตกต่างจากใน SVN ที่ต้องมีการเชื่อมต่ออินเทอร์เน็ตทุกครั้งที่คอมมิต
| ปัจจัย | ไป | SVN |
|---|---|---|
| Archiเทคเจอร์ | กระจาย | ส่วนกลาง |
| ความเร็ว | ได้เร็วขึ้น | ช้าลง |
| งานออฟไลน์ | ที่สนับสนุน | ไม่ได้รับการสนับสนุน |
| การแตกแขนง | มีน้ำหนักเบา | หนักและช้า |
👉 ดาวน์โหลด PDF ฟรี: คำถามและคำตอบสัมภาษณ์ GIT
2) อธิบายเวิร์กโฟลว์และวงจรชีวิตของไฟล์ Git
วงจรชีวิตไฟล์ Git แสดงถึงวิธีการเคลื่อนย้ายไฟล์ผ่านสถานะต่างๆ ในที่เก็บ
ไฟล์ใน Git สามารถมีอยู่ในสถานะหลักสี่สถานะดังต่อไปนี้: ไม่ได้ติดตาม, แก้ไข, ฉากและ ความมุ่งมั่น.
- ไม่ได้ติดตาม: ไฟล์ที่สร้างใหม่ยังไม่ได้เพิ่มไปยัง Git
- แก้ไข: ไฟล์ที่ได้รับการแก้ไขตั้งแต่การคอมมิทครั้งล่าสุด
- จัดฉาก: ไฟล์ที่เพิ่มโดยใช้
git addและพร้อมที่จะมุ่งมั่น - มุ่งมั่น: ไฟล์ที่บันทึกถาวรไปยังที่เก็บด้วย
git commit.
ตัวอย่าง: นักพัฒนาสร้างไฟล์ใหม่ → รัน git add → จากนั้นจึงทำการคอมมิต ลำดับนี้จะทำให้วงจรชีวิตของไฟล์สมบูรณ์ตั้งแต่ไม่มีการติดตามจนถึงการคอมมิต
3) การแตกสาขาและการผสานทำงานใน Git อย่างไร
การแบ่งสาขาช่วยให้นักพัฒนาหลายคนสามารถทำงานกับฟีเจอร์ต่างๆ พร้อมกันโดยไม่กระทบต่อฐานโค้ดหลัก แต่ละสาขาแสดงถึงสายการพัฒนาที่เป็นอิสระ
การผสานจะรวมการเปลี่ยนแปลงจากสาขาหนึ่งเข้าเป็นอีกสาขาหนึ่ง โดยทั่วไปจะรวมสาขาฟีเจอร์กลับเข้าไปในสาขาหลักอีกครั้ง
ตัวอย่าง: หากคุณสร้าง feature/login สาขาทำงานอย่างอิสระแล้วจึงรวมเข้ากับ mainคุณสามารถรวมฟีเจอร์ใหม่ของคุณได้อย่างปลอดภัย
| คำสั่ง | จุดมุ่งหมาย |
|---|---|
git branch feature |
สร้างสาขาใหม่ |
git checkout feature |
สลับไปที่สาขา |
git merge feature |
รวมกับสาขาหลัก |
4) Git Objects มีกี่ประเภท?
Git จัดเก็บข้อมูลเป็นออบเจ็กต์ในฐานข้อมูลภายใน ออบเจ็กต์แบ่งออกเป็น 4 ประเภทหลัก ได้แก่:
- หยด: จัดเก็บข้อมูลไฟล์
- ต้นไม้: แสดงไดเรกทอรีและโครงสร้างไฟล์
- สัญญา: บันทึกการเปลี่ยนแปลงด้วยข้อมูลเมตา เช่น ผู้เขียน วันที่ และข้อมูลที่ส่งมาเหนือ
- คีย์เวิร์ด: ทำเครื่องหมายจุดที่เฉพาะเจาะจงในประวัติศาสตร์ มักใช้สำหรับการเผยแพร่
วัตถุเหล่านี้สร้างความสมบูรณ์และความไม่เปลี่ยนแปลงของ Git เพื่อให้แน่ใจว่าการคอมมิตแต่ละครั้งสามารถระบุได้เฉพาะผ่านแฮช SHA-1
5) ความแตกต่างระหว่าง Git fetch และ Git pull คืออะไร?
git fetch ดาวน์โหลดการเปลี่ยนแปลงจากที่เก็บข้อมูลระยะไกล แต่ไม่รวมการเปลี่ยนแปลงเหล่านั้นโดยอัตโนมัติ ระบบจะอัปเดตสาขาการติดตามระยะไกลในเครื่องของคุณ
git pull ดำเนินการทั้งการดึงข้อมูลและการรวมกันในขั้นตอนเดียว
| คำสั่ง | Descriptไอออน | ใช้กรณี |
|---|---|---|
git fetch |
ดาวน์โหลดการเปลี่ยนแปลงโดยไม่ต้องรวม | เมื่อคุณต้องการตรวจสอบการอัปเดตก่อนการผสาน |
git pull |
ดาวน์โหลดและรวมการเปลี่ยนแปลงโดยอัตโนมัติ | เมื่อคุณต้องการการซิงโครไนซ์ทันที |
ตัวอย่าง: ใช้ git fetch เมื่อทำงานร่วมกันเพื่อตรวจสอบการเปลี่ยนแปลงของผู้อื่นก่อนที่จะรวมกัน
6) Git ตรวจสอบความสมบูรณ์ของข้อมูลได้อย่างไร
Git ช่วยให้มั่นใจถึงความสมบูรณ์ของข้อมูลผ่าน การแฮช SHA-1ทุกคอมมิต ทรี และบล็อบจะถูกระบุด้วยแฮช 40 อักขระเฉพาะ วิธีนี้รับประกันว่าแม้การเปลี่ยนแปลงบิตเพียงเล็กน้อยก็จะเปลี่ยนแปลงแฮช ป้องกันการเสียหายหรือการถูกแทรกแซง
นอกจากนี้ Git ยังใช้ กำกับกราฟ acyclic (DAG) โครงสร้างที่การคอมมิตอ้างอิงถึงการคอมมิตหลัก เพื่อให้แน่ใจว่าประวัติมีความสอดคล้องและสามารถตรวจสอบได้
ตัวอย่าง: หากเนื้อหาของไฟล์มีการเปลี่ยนแปลง ค่า SHA-1 ก็จะเปลี่ยนแปลงไปด้วย ดังนั้น Git จะจดจำว่าเป็นเวอร์ชันใหม่ทันที
7) อธิบาย Git Rebase และความแตกต่างจาก Git Merge
ทั้งสอง git merge และ git rebase บูรณาการการเปลี่ยนแปลงจากสาขาหนึ่งไปสู่อีกสาขาหนึ่ง แต่มีแนวทางที่แตกต่างกัน
- ผสาน: สร้างการรวมใหม่ที่รวมประวัติเข้าด้วยกัน
- รีเบส: ย้ายหรือเล่นซ้ำการกระทำจากสาขาหนึ่งไปยังอีกสาขาหนึ่ง ทำให้เกิดประวัติเชิงเส้น
| ปัจจัย | ผสาน | rebase |
|---|---|---|
| ประวัติการยืนยัน | ไม่เป็นเชิงเส้น | วัดเชิงเส้น |
| สร้างคอมมิทใหม่แล้ว | ใช่ | ไม่ |
| ใช้กรณี | อนุรักษ์ประวัติศาสตร์ | ประวัติการทำความสะอาด |
ตัวอย่าง: ใช้ git rebase เพื่อรักษาประวัติโครงการให้สะอาดในขณะที่ git merge จะดีกว่าสำหรับสาขาสาธารณะที่ใช้ร่วมกัน
8) Git hooks คืออะไร และมีประโยชน์อะไรบ้าง?
Git hooks คือสคริปต์แบบกำหนดเองที่เรียกใช้งานตามเหตุการณ์เฉพาะของ Git เช่น การคอมมิต การผสาน หรือการพุช สคริปต์เหล่านี้ช่วยบังคับใช้มาตรฐานการเขียนโค้ดและทำให้เวิร์กโฟลว์เป็นแบบอัตโนมัติ
ประเภทของตะขอ:
- ฮุกด้านไคลเอนต์: ดำเนินการบนการดำเนินการภายในเครื่อง (เช่น ก่อนการคอมมิต)
- ฮุกด้านเซิร์ฟเวอร์: รันบนการดำเนินการที่เก็บข้อมูลระยะไกล (เช่น รับล่วงหน้า)
ประโยชน์ที่ได้รับ:
- ป้องกันการคอมมิทที่มีข้อผิดพลาดด้านการจัดรูปแบบ
- ทำให้การลินต์หรือทดสอบโค้ดเป็นแบบอัตโนมัติ
- รับรองเวิร์กโฟลว์ที่สอดคล้องกันระหว่างทีมต่างๆ
ตัวอย่าง: A pre-commit Hook สามารถปฏิเสธการยืนยันได้หากการทดสอบยูนิตล้มเหลว
9) ข้อดีและข้อเสียของการใช้ Git มีอะไรบ้าง?
| แง่มุม | ข้อดี | ข้อเสีย |
|---|---|---|
| ประสิทธิภาพ | รวดเร็วและมีประสิทธิภาพสำหรับการแยกสาขา/การผสาน | อาจจะซับซ้อนสำหรับผู้เริ่มต้น |
| การร่วมมือ | ช่วยให้การพัฒนาแบบกระจายเป็นไปได้ | ความขัดแย้งในการรวมที่อาจเกิดขึ้น |
| ความยืดหยุ่น | ทำงานแบบออฟไลน์ | ต้องมีการตั้งค่าและการเรียนรู้ |
| พื้นที่จัดเก็บ | จัดการโครงการขนาดใหญ่ | พื้นที่เก็บข้อมูลอาจเพิ่มขึ้นอย่างรวดเร็ว |
โดยรวมแล้วโมเดลแบบกระจาย ความสมบูรณ์ของข้อมูล และความยืดหยุ่นของ Git ทำให้เป็นมาตรฐานอุตสาหกรรม แม้ว่านักพัฒนาหน้าใหม่ยังต้องเรียนรู้อีกมาก
10) คุณจะแก้ไขข้อขัดแย้งในการผสานใน Git ได้อย่างไร
ความขัดแย้งในการผสานเกิดขึ้นเมื่อ Git ไม่สามารถประสานการเปลี่ยนแปลงระหว่างสาขาได้โดยอัตโนมัติ
ขั้นตอนการแก้ไข:
- ระบุไฟล์ที่ขัดแย้งด้วย
git status. - เปิดไฟล์ ค้นหาเครื่องหมายความขัดแย้ง (
<<<<<<<,=======,>>>>>>>). - แก้ไขไฟล์ด้วยตนเองเพื่อเลือกหรือรวมการเปลี่ยนแปลง
- จัดเตรียมไฟล์โดยใช้
git add. - ยืนยันการผสานที่ได้รับการแก้ไขด้วย
git commit.
ตัวอย่าง: เมื่อนักพัฒนาสองคนแก้ไขบรรทัดเดียวกันในไฟล์บนสาขาที่แตกต่างกัน Git จะสร้างข้อขัดแย้งระหว่างการผสาน ซึ่งต้องมีการแก้ไขด้วยตนเอง
11) ความแตกต่างระหว่าง git reset, git revert และ git checkout คืออะไร
คำสั่งทั้งสามนี้ปรับเปลี่ยนประวัติ Git แตกต่างกันและมีจุดประสงค์ที่แตกต่างกัน
| คำสั่ง | ฟังก์ชัน | ผลกระทบต่อข้อมูล | ใช้กรณี |
|---|---|---|---|
git reset |
ย้ายตัวชี้ HEAD ย้อนกลับไปยังคอมมิทที่ระบุ | ประวัติการกระทำการเปลี่ยนแปลง | เลิกทำการคอมมิตในเครื่อง |
git revert |
สร้างคอมมิตใหม่ที่เลิกทำการเปลี่ยนแปลงก่อนหน้า | เก็บรักษาประวัติการกระทำ | เลิกทำการคอมมิตในสาขาที่ใช้ร่วมกันอย่างปลอดภัย |
git checkout |
สลับสาขาหรือคืนค่าไฟล์ | ไม่ส่งผลกระทบต่อประวัติการกระทำ | ย้ายระหว่างสาขาหรือละทิ้งการเปลี่ยนแปลงในพื้นที่ |
ตัวอย่าง: หากคุณกรอกข้อมูลที่ละเอียดอ่อนโดยไม่ได้ตั้งใจ ให้ใช้ git revert เพื่อเลิกทำอย่างปลอดภัยโดยไม่ต้องเปลี่ยนประวัติการยืนยัน
ใช้ git reset --hard เฉพาะการแก้ไขในพื้นที่ก่อนการผลักดัน
12) อธิบายประเภทของการรีเซ็ตใน Git
Git จัดให้มีการรีเซ็ตหลักสามประเภทขึ้นอยู่กับว่าคุณต้องการเลิกทำการเปลี่ยนแปลงเมื่อใด
| ประเภท | คำสั่ง | พฤติกรรม |
|---|---|---|
| เค้ก | git reset --soft <commit> |
ย้าย HEAD แต่ยังคงดัชนีและไดเร็กทอรีการทำงานไว้เหมือนเดิม |
| สีผสม | git reset --mixed <commit> |
ย้าย HEAD และรีเซ็ตดัชนี การเปลี่ยนแปลงยังคงอยู่ในไดเร็กทอรีการทำงาน |
| ยาก | git reset --hard <commit> |
รีเซ็ต HEAD, ดัชนี และไดเร็กทอรีการทำงานทั้งหมด |
ตัวอย่าง: หากคุณทำการเปลี่ยนแปลงก่อนกำหนด git reset --soft HEAD~1 ช่วยให้คุณสามารถยืนยันอีกครั้งหลังจากการแก้ไข
13) Git Stash คืออะไร และคุณควรใช้มันเมื่อใด?
git stash จัดเก็บการเปลี่ยนแปลงที่ยังไม่ได้ยืนยันชั่วคราว ช่วยให้คุณสามารถสลับสาขาได้โดยไม่สูญเสียงาน
สิ่งนี้มีประโยชน์อย่างยิ่งในระหว่างการทำงานหลายอย่างพร้อมกันหรือเมื่อคุณต้องตรวจสอบสาขาอื่นอย่างเร่งด่วน
คำสั่งทั่วไป:
git stash:บันทึกการปรับเปลี่ยนในเครื่องของคุณgit stash pop: คืนค่าการเปลี่ยนแปลงที่ถูกซ่อนไว้git stash list: แสดงรายการสะสมที่บันทึกไว้ทั้งหมด
ตัวอย่าง: หากคุณดำเนินการนำฟีเจอร์บางอย่างไปใช้ครึ่งทางแล้วเกิดปัญหาในการผลิต ให้เก็บการเปลี่ยนแปลงของคุณไว้ แก้ไขปัญหา แล้วนำงานที่เก็บไว้กลับมาใช้ใหม่
14) Git จัดการกับที่เก็บข้อมูลระยะไกลอย่างไร
ที่เก็บข้อมูลระยะไกลใน Git คือเวอร์ชันของโครงการของคุณที่โฮสต์อยู่บนอินเทอร์เน็ตหรือเครือข่าย ซึ่งใช้สำหรับการทำงานร่วมกันระหว่างนักพัฒนา
คำสั่งระยะไกลทั่วไป:
| คำสั่ง | Descriptไอออน |
|---|---|
git remote add origin <url> |
เชื่อมโยงที่เก็บข้อมูลในเครื่องกับรีโมต |
git push |
ส่งการยืนยันไปยังที่เก็บข้อมูลระยะไกล |
git pull |
ดึงข้อมูลและรวมการเปลี่ยนแปลง |
git fetch |
ดึงข้อมูลแต่ไม่รวมการเปลี่ยนแปลง |
ตัวอย่าง: โดยทั่วไป นักพัฒนาจะโคลนที่เก็บข้อมูลระยะไกลจากแพลตฟอร์มเช่น GitHub หรือ GitLab เพื่อมีส่วนสนับสนุนโครงการที่ใช้ร่วมกัน
15) Git tags คืออะไร และเหตุใดจึงสำคัญ?
แท็กเป็นตัวชี้ไปยังการคอมมิทที่เฉพาะเจาะจง มักใช้เพื่อทำเครื่องหมายจุดเผยแพร่ (เช่น v1.0, v2.1).
พวกเขาให้เสถียรภาพโดยการอ้างอิงเวอร์ชันที่ไม่เปลี่ยนแปลงของฐานโค้ด
ประเภทของแท็ก:
- แท็กน้ำหนักเบา: การอ้างอิงการยืนยันแบบง่าย
- แท็กที่มีคำอธิบาย: เก็บข้อมูลเมตา (ผู้แต่ง, ข้อความ, วันที่)
| คำสั่ง | จุดมุ่งหมาย |
|---|---|
git tag v1.0 |
สร้างแท็กน้ำหนักเบา |
git tag -a v2.0 -m "Release 2.0" |
สร้างแท็กพร้อมคำอธิบาย |
git push origin --tags |
ผลักแท็กทั้งหมดไปยังระยะไกล |
ตัวอย่าง: ทีมงานเผยแพร่ใช้แท็กพร้อมคำอธิบายประกอบในการแพ็คเกจและปรับใช้เวอร์ชันผลิตภัณฑ์ที่เสถียร
16) Git Cherry-Pick คืออะไร และมีประโยชน์อย่างไร?
git cherry-pick อนุญาตให้รวมการคอมมิตเฉพาะจากสาขาหนึ่งไปยังอีกสาขาหนึ่งอย่างเลือกได้
สิ่งนี้มีประโยชน์เมื่อคุณต้องการแก้ไขจุดบกพร่องหรือคุณลักษณะเฉพาะโดยไม่ต้องผสานสาขาทั้งหมด
ตัวอย่าง: คุณสามารถแก้ไขได้จาก feature/bugfix ไปยัง main โดยใช้:
git cherry-pick <commit-hash>
ประโยชน์ที่ได้รับ:
- การควบคุมที่แม่นยำเหนือการรวมคอมมิต
- หลีกเลี่ยงการรวมโค้ดที่ไม่จำเป็น
- รักษาประวัติความสะอาดในสาขาที่สำคัญ
17) Git Squash คืออะไร และมีประโยชน์อะไรบ้าง?
การรวมข้อมูลใน Git จะรวมข้อมูลหลายรายการเข้าเป็นรายการเดียว ทำให้ประวัติข้อมูลมีความสมบูรณ์และเรียบง่ายขึ้น
คำสั่ง:
git rebase -i HEAD~3
จากนั้นเลือก squash ตัวเลือกสำหรับการยืนยันที่คุณต้องการผสาน
ประโยชน์ที่ได้รับ:
- สร้างประวัติศาสตร์อันกระชับ
- ทำให้คำขอการดึงข้อมูลง่ายต่อการตรวจสอบ
- ลดความยุ่งวุ่นวายจากการกระทำเล็กๆ น้อยๆ
ตัวอย่าง: ก่อนที่จะรวมสาขาฟีเจอร์ นักพัฒนาจะรวมคอมมิตเล็กๆ น้อยๆ ทั้งหมดให้กลายเป็นคอมมิตเดียวที่มีความหมาย
18) คุณสามารถย้อนกลับการคอมมิตที่ถูกพุชใน Git ได้อย่างไร?
เมื่อทำการส่งคอมมิตไปยังที่เก็บข้อมูลระยะไกลแล้ว จะไม่สามารถลบได้อย่างปลอดภัย แต่สามารถย้อนกลับได้โดยใช้:
git revert <commit-hash> git push origin main
ความแตกต่างระหว่างการรีเซ็ตและ Revเอิร์ท:
| ปัจจัย | รีเซ็ต | Revเอิร์ท |
|---|---|---|
| ประวัติขององค์กร | เขียนประวัติศาสตร์ใหม่ | อนุรักษ์ประวัติศาสตร์ |
| ความปลอดภัย | ไม่ปลอดภัยสำหรับที่เก็บข้อมูลที่ใช้ร่วมกัน | ปลอดภัยสำหรับสาขาสาธารณะ |
| การใช้ | การเลิกทำในเครื่อง | การเลิกทำระยะไกล |
ตัวอย่าง: หากมีการคอมมิทที่ผิดพลาดอยู่แล้วบน GitHub ให้ใช้ git revert แทน git reset เพื่อรักษาประวัติศาสตร์ร่วมกันให้สอดคล้องกัน
19) ความแตกต่างระหว่าง Git และ GitHub คืออะไร?
Git เป็น เครื่องมือควบคุมเวอร์ชันในขณะที่ GitHub เป็น แพลตฟอร์มบนคลาวด์ สำหรับการโฮสต์คลังข้อมูล Git
| แง่มุม | ไป | GitHub |
|---|---|---|
| ธรรมชาติ | เครื่องมือบรรทัดคำสั่ง | บริการบนเว็บ |
| ฟังก์ชัน | ติดตามการเปลี่ยนแปลงรหัสภายในเครื่อง | ช่วยให้สามารถทำงานร่วมกันจากระยะไกลได้ |
| ความต้องการทางอินเทอร์เน็ต | สามารถเลือกหรือไม่เลือกก็ได้ | ต้อง |
| กรรมสิทธิ์ | โอเพ่นซอร์ส (โดย Linus Torvalds) | ที่เป็นเจ้าของโดย Microsoft |
ตัวอย่าง: นักพัฒนาใช้ Git เพื่อจัดการเวอร์ชันของโค้ดต้นฉบับในเครื่อง และใช้ GitHub เพื่อแบ่งปันและตรวจสอบโค้ดกับเพื่อนร่วมทีม
20) กลยุทธ์การรวม Git ที่แตกต่างกันมีอะไรบ้าง
Git มีกลยุทธ์ในการผสานหลายวิธี ขึ้นอยู่กับว่าคุณต้องการรวมการเปลี่ยนแปลงอย่างไร
| กลยุทธ์ | Descriptไอออน | ใช้กรณี |
|---|---|---|
| ซ้ำ | ค่าเริ่มต้น; รวมสองสาขา | การผสานมาตรฐาน |
| ของเราเอง | เก็บการเปลี่ยนแปลงของสาขาปัจจุบัน | การยกเลิกการเปลี่ยนแปลงที่เข้ามา |
| ของพวกเขา | เก็บการเปลี่ยนแปลงของสาขาขาเข้า | การแทนที่การเปลี่ยนแปลงในท้องถิ่น |
| ปลาหมึกยักษ์ | รวมสาขาหลายสาขาพร้อมกัน | สาขาการบูรณาการ |
ตัวอย่าง: ในระหว่างการรวมที่ซับซ้อน นักพัฒนาอาจใช้ recursive กลยุทธ์สำหรับการผสานมาตรฐานหรือ ours เพื่อให้ความสำคัญกับการเปลี่ยนแปลงในระดับท้องถิ่น
21) Detached HEAD ใน Git คืออะไร และจะแก้ไขได้อย่างไร
A หัวแยก เกิดขึ้นเมื่อ HEAD ตัวชี้ไม่ได้ชี้ไปที่สาขา แต่ชี้ไปที่คอมมิตเฉพาะเจาะจง สิ่งนี้จะเกิดขึ้นเมื่อคุณตรวจสอบคอมมิตก่อนหน้าโดยตรงโดยใช้:
git checkout <commit-hash>
ในสถานะนี้ การคอมมิตใหม่ใดๆ จะไม่เชื่อมโยงกับสาขา และอาจสูญหายได้หากไม่มีการอ้างอิงอย่างถูกต้อง
วิธีแก้ปัญหา:
- สร้างสาขาใหม่จากสถานะแยก:
git checkout -b temp-branch
- จากนั้นทำการคอมมิทหรือรวมตามปกติ
ตัวอย่าง: เมื่อทดสอบโค้ดเวอร์ชันเก่า คุณอาจป้อน HEAD ที่แยกออกมา ควรสร้าง branch เสมอเพื่อเก็บการเปลี่ยนแปลงไว้
22) จุดประสงค์ของ git reflog คืออะไร และคุณควรใช้มันเมื่อใด?
git reflog เป็นคำสั่งอันทรงพลังที่ติดตามการเคลื่อนไหวทั้งหมดของ HEAD ตัวชี้ แม้กระทั่งตัวชี้ที่ไม่ได้เป็นส่วนหนึ่งของประวัติสาขาที่มองเห็นได้ ทำหน้าที่เป็นตาข่ายนิรภัยสำหรับการกู้คืนคอมมิตที่หายไป
การใช้งาน:
git reflog git checkout <commit-hash>
ตัวอย่าง:
หากคุณวิ่งโดยไม่ได้ตั้งใจ git reset --hard และสูญเสียการกระทำล่าสุด git reflog ช่วยให้คุณค้นหาและเรียกคืนได้
ประโยชน์ที่ได้รับ:
- กู้คืนงานที่สูญหายหลังจากการรีเบสหรือรีเซ็ตผิดพลาด
- ให้ประวัติการนำทางการยืนยันโดยละเอียด
- เพิ่มความปลอดภัยในขั้นตอนการทำงานที่ซับซ้อน
23) อธิบาย Git Submodules และกรณีการใช้งาน
A Git ซับโมดูล ช่วยให้คุณสามารถรวมคลังเก็บ Git หนึ่งไว้เป็นโฟลเดอร์ย่อยภายในคลังเก็บอื่นได้ ใช้สำหรับจัดการโปรเจกต์ที่ต้องพึ่งพาคลังเก็บอื่น
คำสั่งทั่วไป:
git submodule add <repo-url> git submodule update --init
ตัวอย่าง: แอปพลิเคชันเว็บอาจรวมถึงโมดูลการตรวจสอบสิทธิ์ที่ใช้ร่วมกันเป็นซับโมดูล Git ในหลายโครงการ
| ข้อดี | ข้อเสีย |
|---|---|
| Promoการนำโค้ด tes มาใช้ซ้ำ | อาจทำให้กระบวนการ CI/CD มีความซับซ้อน |
| รักษาประวัติที่เป็นอิสระ | ต้องมีการอัปเดตด้วยตนเอง |
| รับประกันความสอดคล้องของเวอร์ชัน | เส้นโค้งการเรียนรู้ที่สูงขึ้น |
24) เวิร์กโฟลว์ Git คืออะไร และมีประเภทใดบ้าง
เวิร์กโฟลว์ Git กำหนดแนวทางแบบมีโครงสร้างที่ทีมต่างๆ ใช้ในการทำงานร่วมกับ Git ประเภทที่ได้รับความนิยมมากที่สุด ได้แก่:
| Workflow | Descriptไอออน | ใช้กรณี |
|---|---|---|
| การไหลของ Git | ใช้คุณลักษณะ พัฒนา และเผยแพร่สาขา | โครงการขนาดใหญ่ |
| การไหลของ GitHub | การไหลแบบง่ายโดยใช้สาขาหลักและสาขาคุณลักษณะ | การปรับใช้อย่างต่อเนื่อง |
| การไหลของ GitLab | รวม Git Flow เข้ากับการรวม CI/CD | โครงการที่มุ่งเน้น DevOps |
| พื้นฐานแบบทรังค์ | นักพัฒนามุ่งมั่นที่จะใช้สาขาที่ใช้ร่วมกันเพียงแห่งเดียว | ทีมงานส่งมอบที่คล่องตัวและรวดเร็ว |
ตัวอย่าง: สตาร์ทอัพมักจะนำมาใช้ พื้นฐานแบบทรังค์ เวิร์กโฟลว์เพื่อความเร็ว ในขณะที่องค์กรต่างๆ นิยม การไหลของ Git สำหรับการปล่อยแบบควบคุม
25) Git Bisect คืออะไร และช่วยในการดีบักได้อย่างไร
git bisect เป็นเครื่องมือแก้ไขจุดบกพร่องอันทรงพลังที่ใช้การค้นหาแบบไบนารีเพื่อระบุคอมมิทที่ทำให้เกิดจุดบกพร่อง
ขั้นตอนการทำงานตัวอย่าง:
- เริ่มแบ่งครึ่ง:
git bisect start - ทำเครื่องหมายการกระทำปัจจุบันว่าไม่ดี:
git bisect bad - ทำเครื่องหมายการกระทำที่ดีครั้งสุดท้ายที่ทราบ:
git bisect good <commit> - Git ตรวจสอบจุดกึ่งกลางโดยอัตโนมัติ
- ทดสอบและดำเนินการต่อจนกว่าจะพบการกระทำที่ผิดพลาด
ประโยชน์ที่ได้รับ:
- เพิ่มความเร็วในการติดตามจุดบกพร่องในฐานโค้ดขนาดใหญ่
- ลดการตรวจสอบการกระทำด้วยตนเอง
- เหมาะสำหรับการทดสอบการถดถอย CI/CD
26) ความแตกต่างระหว่าง Git Merge Conflict และ Rebase Conflict คืออะไร
ทั้งสองอย่างนี้เกิดขึ้นเมื่อ Git ไม่สามารถปรับความแตกต่างของโค้ดได้โดยอัตโนมัติ แต่เกิดขึ้นในบริบทที่แตกต่างกัน
| ประเภท | เมื่อมันเกิดขึ้น | ความละเอียด |
|---|---|---|
| รวมความขัดแย้ง | ในระหว่าง git merge ระหว่างสาขา |
แก้ไขในสาขาเป้าหมาย |
| ความขัดแย้งในการรีเบส | ในระหว่าง git rebase ขณะกำลังเล่นซ้ำการกระทำ |
แก้ไขในขณะที่สร้างฐานใหม่ จากนั้นดำเนินการต่อด้วย git rebase --continue |
ตัวอย่าง: หากแก้ไขบรรทัดเดียวกันต่างกันในสองสาขา จะเกิดข้อขัดแย้งในการผสาน ระหว่างการสร้างฐานใหม่ การเปลี่ยนแปลงที่คล้ายกันจะกระตุ้นให้เกิดข้อขัดแย้งในการสร้างฐานใหม่ด้วย
27) สามารถรวม Git เข้ากับ CI/CD pipeline ได้อย่างไร
Git สร้างรากฐานให้กับเวิร์กโฟลว์ CI/CD สมัยใหม่ด้วยการเรียกใช้กระบวนการอัตโนมัติในแต่ละคอมมิตหรือดึงคำขอ
ตัวอย่างการบูรณาการ:
- การยืนยันการผลักดัน → ทริกเกอร์ไปป์ไลน์ CI (ผ่าน Jenkins, GitHub Actions หรือ GitLab CI)
- สร้างและทดสอบ → การทดสอบอัตโนมัติจะตรวจสอบความถูกต้องของการยืนยัน
- ปรับใช้ → การเปลี่ยนแปลงจะถูกผลักดันไปสู่การจัดเตรียมหรือการผลิต
ประโยชน์ที่ได้รับ:
- รับประกันการใช้งานที่สอดคล้องกัน
- ช่วยให้เกิดรอบการตอบรับที่รวดเร็ว
- ลดข้อผิดพลาดของมนุษย์ในการเผยแพร่
ตัวอย่าง: GitHub Actions สามารถทดสอบและปรับใช้โครงการโดยอัตโนมัติเมื่อมีการเปลี่ยนแปลงเกิดขึ้น main สาขา.
28) ความแตกต่างระหว่าง git clean และ git reset คืออะไร?
| คำสั่ง | จุดมุ่งหมาย | ขอบเขต | ตัวอย่าง |
|---|---|---|---|
git clean |
ลบไฟล์ที่ไม่ได้ติดตาม | ไดเรกทอรีการทำงาน | git clean -f -d |
git reset |
ย้ายตัวชี้ HEAD | คอมมิต ดัชนี และเวิร์กทรี | git reset --hard HEAD~1 |
ตัวอย่าง: หากพื้นที่ทำงานของคุณมีไฟล์ชั่วคราวหรือไฟล์ที่สร้างขึ้นซึ่ง Git ไม่สามารถติดตามได้ ให้ใช้ git cleanหากคุณต้องการเลิกทำการคอมมิต ให้ใช้ git reset.
เคล็ดลับ: ตรวจสอบเสมอด้วย git clean -n ก่อนดำเนินการเพื่อหลีกเลี่ยงการลบโดยไม่ได้ตั้งใจ
29) Git Reflog เทียบกับ Git Log คืออะไร?
แม้ว่าทั้งสองจะแสดงประวัติการกระทำ แต่มีวัตถุประสงค์ที่แตกต่างกัน
| คำสั่ง | แทร็ค | รวมถึงการลบคอมมิต | ใช้กรณี |
|---|---|---|---|
git log |
ประวัติการกระทำที่มองเห็นได้ | ไม่ | Revความคืบหน้าโครงการดู |
git reflog |
การเคลื่อนไหวของศีรษะทั้งหมด | ใช่ | กู้คืนการกระทำที่สูญหาย |
ตัวอย่าง: หลังจากลบสาขาโดยไม่ได้ตั้งใจ คุณสามารถใช้ git reflog เพื่อค้นหาและกู้คืนการกระทำครั้งสุดท้ายซึ่งจะไม่ปรากฏใน git log.
30) แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้ Git อย่างมีประสิทธิภาพในทีมงานขนาดใหญ่มีอะไรบ้าง
- ใช้ข้อตกลงการตั้งชื่อสาขา: ปฏิบัติตามรูปแบบเช่น
feature/login-ui or bugfix/payment. - มุ่งมั่นบ่อยครั้งแต่มีคุณค่า: ให้แต่ละคอมมิทมุ่งเน้นไปที่การเปลี่ยนแปลงเชิงตรรกะเพียงหนึ่งเดียว
- เขียน Descriptive Commit Messages: ใช้โหมดบังคับ เช่น
"Fix user login validation." - Rebase ก่อนการผสาน: รักษาประวัติการส่งให้สะอาด
- ใช้ Pull Request สำหรับ Revนั่นคือ: Promoความร่วมมือและคุณภาพของโค้ด
- ปล่อยแท็กอย่างสม่ำเสมอ: ช่วยควบคุมเวอร์ชันและย้อนกลับ
- การทดสอบอัตโนมัติผ่าน CI/CD: รับประกันการบูรณาการที่เสถียรและการเผยแพร่ที่รวดเร็วยิ่งขึ้น
ตัวอย่าง: ในการพัฒนาองค์กร การใช้ Git อย่างมีโครงสร้างจะช่วยป้องกันความขัดแย้งและทำให้การจัดการการเผยแพร่ง่ายขึ้น
31) Git Internals คืออะไร และ Git จัดเก็บข้อมูลอย่างไร
Git Internals หมายถึงสถาปัตยกรรมระดับต่ำที่ขับเคลื่อนการทำงานของ Git Git จัดเก็บทุกอย่าง (ไฟล์ ไดเรกทอรี การคอมมิต) ไว้เป็น วัตถุ ที่ .git/objects ไดเรกทอรี วัตถุเหล่านี้จะถูกระบุโดย แฮช SHA-1 และจัดอยู่ในหมวดหมู่ บล็อบ ต้นไม้ คอมมิต และแท็ก.
วงจรชีวิตการจัดเก็บข้อมูล:
- เมื่อเพิ่มไฟล์ เนื้อหาจะถูกเก็บไว้เป็น
blob. - A
treeโครงสร้างไฟล์แผนที่ - A
commitเชื่อมโยงต้นไม้และข้อมูลเมตา - A
tagการอ้างอิงการยืนยันสำหรับการเปิดตัว
ตัวอย่าง: เล่น git cat-file -p <hash> ช่วยให้คุณสามารถตรวจสอบวัตถุ Git ได้โดยตรง
การออกแบบนี้ช่วยให้มั่นใจ ความสมบูรณ์ของข้อมูล, การตรวจสอบย้อนกลับเวอร์ชันและ ประสิทธิภาพน้ำหนักเบาทำให้ Git มีประสิทธิภาพสูงเมื่อเทียบกับระบบเก่าอย่าง SVN
32) ความแตกต่างระหว่าง Git Rebase Interactive และ Git Merge คืออะไร?
| ปัจจัย | Git Rebase แบบโต้ตอบ (git rebase -i) |
การผสาน Git |
|---|---|---|
| จุดมุ่งหมาย | อนุญาตให้แก้ไข จัดเรียงใหม่ และบีบอัดคอมมิท | รวมประวัติศาสตร์ |
| ประวัติขององค์กร | เขียนประวัติศาสตร์ใหม่ | รักษาการคอมมิตทั้งหมด |
| ใช้กรณี | การทำความสะอาดก่อนการผสาน | การรักษาไทม์ไลน์ดั้งเดิม |
ตัวอย่าง: ก่อนที่จะรวมสาขาฟีเจอร์ นักพัฒนาอาจใช้:
git rebase -i main
เพื่อลบการคอมมิทที่ไม่จำเป็นและสร้างประวัติเชิงเส้นที่สะอาดขึ้น
ผสาน ปลอดภัยกว่าสำหรับสาขาที่ร่วมมือกันในขณะที่ รีเบส เพิ่มความสามารถในการอ่านสำหรับเวิร์กโฟลว์การพัฒนาส่วนตัว
33) Sparse Checkout ใน Git คืออะไร และมีประโยชน์อะไรบ้าง?
การชำระเงินแบบเบาบาง ช่วยให้นักพัฒนาสามารถโคลนหรือทำงานกับไฟล์เพียงบางส่วนจากที่เก็บข้อมูลขนาดใหญ่ได้ ช่วยลดการใช้พื้นที่เก็บข้อมูลในเครื่องและเพิ่มความเร็วในการทำงาน
คำสั่ง:
git clone --no-checkout <repo-url> git sparse-checkout init --cone git sparse-checkout set <folder-path>
ประโยชน์ที่ได้รับ:
- ปรับปรุงประสิทธิภาพการทำงานใน monorepos
- ลดการใช้งานดิสก์
- เหมาะสำหรับสถาปัตยกรรมไมโครเซอร์วิส
ตัวอย่าง: ในโครงการองค์กรขนาดใหญ่ นักพัฒนาอาจต้องการเพียง /frontend โฟลเดอร์ Sparse Checkout จะดาวน์โหลดเฉพาะไดเรกทอรีนั้นเท่านั้น โดยหลีกเลี่ยงการใช้โค้ดแบ็กเอนด์ขนาดหลายกิกะไบต์ที่ไม่จำเป็น
34) Shallow Clone คืออะไร และควรใช้เมื่อใด?
A โคลนตื้น ดาวน์โหลดเพียงส่วนหนึ่งของประวัติของที่เก็บข้อมูลเท่านั้น ซึ่งทำให้การโคลนเร็วขึ้นมาก
คำสั่ง:
git clone --depth=1 <repo-url>
ประโยชน์ที่ได้รับ:
- ลดเวลาโคลนสำหรับที่เก็บข้อมูลขนาดใหญ่
- ประหยัดแบนด์วิดท์และพื้นที่ดิสก์
- มีประโยชน์สำหรับ CI pipeline ที่ต้องการคอมมิตล่าสุดเท่านั้น
ข้อเสีย:
- ไม่สามารถเข้าถึงคอมมิตเก่าหรือรีเบสเกินความลึกที่ดึงมาได้
- การมองเห็นประวัติศาสตร์ที่จำกัด
ตัวอย่าง: ระบบ CI/CD มักใช้โคลนตื้นๆ เพื่อดึงเวอร์ชันโค้ดล่าสุดอย่างรวดเร็วสำหรับการสร้างอัตโนมัติโดยไม่ต้องมีประวัติการคอมมิตทั้งหมด
35) Git LFS (Large File Storage) คืออะไร และทำไมจึงใช้?
git-lfs (Large File Storage) เป็นส่วนขยายที่แทนที่ไฟล์ขนาดใหญ่ (เช่น รูปภาพ ชุดข้อมูล ไบนารี) ด้วยตัวชี้ข้อความน้ำหนักเบาภายใน Git ในขณะที่จัดเก็บเนื้อหาจริงในเซิร์ฟเวอร์ LFS ระยะไกล
ตัวอย่างคำสั่ง:
git lfs install git lfs track "*.zip"
ข้อดี:
- ช่วยให้ที่เก็บข้อมูลมีน้ำหนักเบา
- ปรับปรุงประสิทธิภาพการทำงานกับไฟล์ไบนารีขนาดใหญ่
- ทำงานร่วมกับ GitHub, GitLab และ Bitbucket ได้อย่างราบรื่น
ตัวอย่าง: ทีมพัฒนาเกมใช้ Git LFS เพื่อจัดการทรัพยากร 3 มิติขนาดใหญ่โดยไม่ทำให้การทำงานปกติของ Git ช้าลง
36) คุณจะกำหนดค่า Git เพื่อประสิทธิภาพที่เหมาะสมที่สุดได้อย่างไร
คุณสามารถปรับปรุงความเร็วและการใช้งานของ Git ได้โดยการปรับแต่งพารามิเตอร์การกำหนดค่า
ปฏิบัติที่ดีที่สุด:
- เปิดใช้งานการบีบอัด:
git config --global core.compression 9 - ตั้งค่า GC อัตโนมัติ (การเก็บขยะ):
git gc --auto - ใช้การดึงข้อมูลแบบขนาน (v2.31+):
git config --global fetch.parallel 4 - เปิดใช้งานการแคชข้อมูลรับรอง:
git config --global credential.helper cache
ตัวอย่าง: สำหรับที่เก็บข้อมูลขนาดองค์กร การเพิ่มประสิทธิภาพการตั้งค่าการดึงและการบีบอัดของ Git ช่วยลดความล่าช้าในการโคลนและการดึงข้อมูลได้อย่างมาก ช่วยปรับปรุงประสิทธิภาพการทำงานในทีมที่กระจายอยู่ทั่วไป
37) Commit Signing (GPG) ใน Git คืออะไร และเหตุใดจึงสำคัญ?
การลงนามยืนยันการใช้งาน GPG (GNU Privacy Guard) เพื่อตรวจสอบความถูกต้องของข้อมูลโดยการเข้ารหัสเพื่อให้แน่ใจว่าการเปลี่ยนแปลงมาจากผู้มีส่วนร่วมที่เชื่อถือได้
ตัวอย่างการตั้งค่า:
git config --global user.signingkey <GPG-key> git commit -S -m "Signed commit"
ประโยชน์ที่ได้รับ:
- ป้องกันการกระทำที่ไม่ได้รับอนุญาตหรือแอบอ้าง
- เพิ่มความปลอดภัยและความสามารถในการตรวจสอบของที่เก็บข้อมูล
- สร้างความไว้วางใจภายในองค์กร
ตัวอย่าง: โครงการโอเพ่นซอร์สมักต้องการการยืนยันการลงนามโดย GPG เพื่อยืนยันความถูกต้องของการมีส่วนร่วมจากนักพัฒนาภายนอก
38) Git จัดการไฟล์ไบนารีแตกต่างจากไฟล์ข้อความอย่างไร
Git ได้รับการปรับให้เหมาะสมสำหรับโค้ดต้นฉบับและแทร็กที่ใช้ข้อความ การเปลี่ยนแปลงทีละบรรทัดซึ่งทำงานได้ไม่ดีนักสำหรับไฟล์ไบนารี ไฟล์ไบนารีจะถูกจัดเก็บเป็นบล็อบเดี่ยวๆ — การแก้ไขใดๆ จะสร้างเวอร์ชันใหม่แทนที่จะเป็น diff
| ชนิดของไฟล์ | ประสิทธิภาพการจัดเก็บ | การสนับสนุนที่แตกต่างกัน | การจัดการที่แนะนำ |
|---|---|---|---|
| ข้อความ | มีประสิทธิภาพมาก | ใช่ | Git เริ่มต้น |
| เลขฐานสอง | ไม่มีประสิทธิภาพ | ไม่ | ใช้ Git LFS |
ตัวอย่าง: สำหรับที่เก็บข้อมูลที่มีรูปภาพจำนวนมาก การเปิดใช้งาน Git LFS จะช่วยป้องกันไม่ให้ประสิทธิภาพลดลงอันเนื่องมาจากการอัปเดตไฟล์ไบนารีบ่อยครั้ง
39) คุณแก้ไขปัญหา Git ทั่วไป เช่น การแยก HEAD หรือข้อผิดพลาดในการผสานได้อย่างไร
ปัญหาทั่วไปและวิธีแก้ไข:
| »ÑËÒ | ก่อให้เกิด | Solution |
|---|---|---|
| หัวแยก | การตรวจสอบการกระทำที่เฉพาะเจาะจง | สร้างสาขาด้วย git checkout -b new-branch |
| รวมความขัดแย้ง | การแก้ไขที่ขัดแย้งในไฟล์ | แก้ไขด้วยตนเองแล้ว git add และ git commit |
| การสูญเสียความมุ่งมั่น | การรีเซ็ตหรือรีเบสโดยไม่ได้ตั้งใจ | ใช้ git reflog การกู้คืน |
| ผลักปฏิเสธ | การอัปเดตระยะไกลข้างหน้า | ดึงหรือเปลี่ยนฐานก่อนผลัก |
ตัวอย่าง: เมื่อเกิดข้อผิดพลาด "ไม่ส่งต่ออย่างรวดเร็ว" มักหมายถึงมีการเปลี่ยนแปลงระยะไกลเกิดขึ้น — ใช้ git pull --rebase เพื่อซิงโครไนซ์ก่อนที่จะลองใหม่อีกครั้ง
40) แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยสำหรับคลัง Git คืออะไร
- ใช้การตรวจสอบสิทธิ์ SSH หรือ HTTPS: หลีกเลี่ยงการใช้ข้อมูลประจำตัวแบบธรรมดา
- เปิดใช้งาน 2FA บนแพลตฟอร์มโฮสติ้ง Git
- หลีกเลี่ยงการเปิดเผยความลับหรือคีย์: ใช้
.gitignoreหรือเครื่องมือเช่น GitGuardian - ลงนามยืนยันด้วยคีย์ GPG
- จำกัดการควบคุมการเข้าถึง: บังคับใช้หลักการสิทธิพิเศษน้อยที่สุด
- ใช้กฎการป้องกันสาขาสำหรับ
mainormaster. - ดำเนินการตรวจสอบที่เก็บข้อมูลเป็นประจำ
ตัวอย่าง: บริษัทต่างๆ มักบูรณาการการสแกนความลับและบังคับใช้การยืนยันที่ลงนามในไปป์ไลน์ CI/CD เพื่อป้องกันการรั่วไหลของข้อมูลและการเปลี่ยนแปลงที่ไม่ได้รับอนุญาต
41) คุณจะทำให้การดำเนินการ Git อัตโนมัติโดยใช้เชลล์หรือ Python สคริปต์?
ระบบอัตโนมัติของ Git ช่วยเพิ่มประสิทธิภาพและความสม่ำเสมอในการทำงานซ้ำๆ เช่น การยืนยัน การรวม และการปรับใช้
ตัวอย่าง – สคริปต์เชลล์:
#!/bin/bash git add . git commit -m "Auto commit on $(date)" git push origin main
ตัวอย่าง - Python สคริปต์ (ใช้ GitPython):
from git import Repo
repo = Repo('.')
repo.git.add(A=True)
repo.index.commit("Automated commit")
origin = repo.remote(name='origin')
origin.push()
ประโยชน์ที่ได้รับ:
- ลดความพยายามในการทำงานด้วยมือ
- รับประกันรูปแบบการกระทำที่สอดคล้องกัน
- บูรณาการกับ CI/CD และ DevOps pipeline ได้อย่างราบรื่น
42) Git Hooks คืออะไร และสามารถใช้ในระบบอัตโนมัติได้อย่างไร
Git ฮุกส์ เป็นสคริปต์ที่ถูกเรียกใช้งานโดยเหตุการณ์ Git เฉพาะ ซึ่งใช้เพื่อบังคับใช้กฎหรือทำให้กระบวนการเป็นอัตโนมัติ
ประเภทของตะขอ:
| ประเภท | วิ่งบน | ตัวอย่าง |
|---|---|---|
| ด้านลูกค้า | เครื่องของนักพัฒนา | pre-commit, prepare-commit-msg |
| ฝั่งเซิร์ฟเวอร์ | ที่เก็บข้อมูลระยะไกล | pre-receive, post-receive |
ตัวอย่าง: A pre-commit hook สามารถรัน linter หรือทดสอบยูนิตก่อนที่จะอนุญาตให้คอมมิทได้
ประโยชน์ที่ได้รับ:
- รักษาคุณภาพของโค้ด
- ป้องกันการละเมิดนโยบาย
- ทำให้งานตรวจสอบซ้ำๆ ในเวิร์กโฟลว์เป็นแบบอัตโนมัติ
43) คุณจะไมเกรชันโครงการจาก SVN หรือ Mercurial ไปยัง Git ได้อย่างไร
การย้ายจากระบบรวมศูนย์เช่น SVN ไปยัง ไป เกี่ยวข้องกับการแปลงแบบมีโครงสร้างเพื่อเก็บรักษาประวัติการส่ง
ขั้นตอน:
- ติดตั้งเครื่องมือการไมเกรชัน:
git svnorsvn2git. - โคลนที่เก็บข้อมูล SVN:
git svn clone <SVN_URL> --trunk=trunk --branches=branches --tags=tags
- แปลงแท็กและสาขา
- ผลักไปยังที่เก็บข้อมูล Git ระยะไกล (เช่น GitHub)
ข้อดี:
- เปิดใช้งานเวิร์กโฟลว์แบบกระจาย
- เพิ่มประสิทธิภาพและความยืดหยุ่น
- ลดความซับซ้อนของการแตกสาขาและการผสาน
ตัวอย่าง: องค์กรที่ย้ายจากระบบ SVN เดิมใช้ svn2git เพื่อรักษาความเป็นผู้ประพันธ์และบันทึกประวัติ
44) ความแตกต่างระหว่าง Git Flow และ Trunk-Based Development คืออะไร
| แง่มุม | การไหลของ Git | การพัฒนาตามลำต้น |
|---|---|---|
| การแตกแขนง | หลายสาขา (พัฒนา, เผยแพร่) | สาขาหลักเดี่ยว |
| รุ่นวางจำหน่าย | รอบการเปิดตัวคงที่ | การปรับใช้อย่างต่อเนื่อง |
| ความซับซ้อน | ปานกลางถึงสูง | ต่ำ |
| ที่ดีที่สุดสำหรับ | ทีมงานขนาดใหญ่และมีเสถียรภาพ | ทีมงานที่คล่องตัวและเคลื่อนไหวรวดเร็ว |
ตัวอย่าง: Git Flow เหมาะที่สุดสำหรับโครงการระดับองค์กรที่มีการเผยแพร่แบบควบคุม ในขณะที่ Trunk-Based เหมาะอย่างยิ่งสำหรับการเริ่มต้นหรือไมโครเซอร์วิสที่ความเร็วเป็นสิ่งสำคัญ
การเปรียบเทียบผลประโยชน์:
- การไหลของ Git: การควบคุมเวอร์ชันที่แข็งแกร่ง
- แบบ Trunk-Based: การตอบรับที่รวดเร็วยิ่งขึ้นและการจัดตำแหน่ง CI/CD
45) กลยุทธ์ใดบ้างที่สามารถเพิ่มประสิทธิภาพการทำงานของ Git สำหรับที่เก็บข้อมูลขนาดใหญ่ได้
สำหรับโครงการระดับองค์กรที่มีการยืนยันหรือผู้สนับสนุนหลายพันรายการ ประสิทธิภาพของ Git อาจลดลงหากไม่ได้รับการปรับให้เหมาะสม
กลยุทธ์การเพิ่มประสิทธิภาพที่สำคัญ:
- ใช้ โคลนตื้น (
--depth=1) เพื่อการชำระเงินที่รวดเร็วยิ่งขึ้น - ใช้ การชำระเงินแบบเบาบาง เพื่อดึงเฉพาะไดเรกทอรีที่เกี่ยวข้องเท่านั้น
- วิ่ง การเก็บขยะ:
git gc --aggressive. - แยก monorepos ออกเป็น submodules หรือ microservices
- บีบอัดวัตถุและแพ็คไฟล์เป็นประจำ
ตัวอย่าง: ใน monorepos ที่เกิน 10 GB การเปิดใช้งานการชำระเงินแบบเบาบางและการรวบรวมขยะปกติจะช่วยลดเวลาการโคลนและการดึงข้อมูลอย่างมาก
46) Git รองรับการพัฒนาแบบร่วมมือกันในทีมแบบกระจายอย่างไร
Git ช่วยให้การทำงานร่วมกันเป็นไปได้ด้วยการกระจายสำเนาของคลังข้อมูลทั้งหมดไปยังนักพัฒนา นักพัฒนาแต่ละคนสามารถคอมมิทในเครื่อง ผลักดันการเปลี่ยนแปลงไปยังรีโมต และผสานรวมงานของผู้อื่นได้
ตัวอย่างเวิร์กโฟลว์การทำงานร่วมกัน:
- ฟอร์กที่เก็บข้อมูล
- สร้างสาขาคุณลักษณะ
- ผลักดันการเปลี่ยนแปลงและเปิดคำขอการดึง
- Revมองและรวมเข้าเป็น
main.
ประโยชน์ที่ได้รับ:
- ช่วยให้สามารถพัฒนาฟีเจอร์แบบคู่ขนานได้
- ช่วยลดปัญหาการพึ่งพา
- รองรับการทำงานแบบออฟไลน์และเวิร์กโฟลว์ที่ยืดหยุ่น
ตัวอย่าง: ผู้สนับสนุนโอเพ่นซอร์สทั่วโลกร่วมมือกันแบบอะซิงโครนัสผ่านการแยกและดึงคำขอที่โฮสต์บน GitHub
47) Git Garbage Collection คืออะไร และเหตุใดจึงสำคัญ?
git gc (การรวบรวมขยะ) ทำความสะอาดไฟล์ที่ไม่จำเป็นและเพิ่มประสิทธิภาพการจัดเก็บโดยการบีบอัดวัตถุและตัดแต่งคอมมิทที่ไม่สามารถเข้าถึงได้
คำสั่ง:
git gc --aggressive --prune=now
ประโยชน์ที่ได้รับ:
- เพิ่มพื้นที่ว่างบนดิสก์
- ปรับปรุงประสิทธิภาพการทำงานของที่เก็บข้อมูล
- ลดความซ้ำซ้อนในวัตถุการยืนยัน
ตัวอย่าง: นักพัฒนามักจะทำงาน git gc หลังการผสานหรือการลบสาขาหลายครั้งเพื่อรักษาสุขภาพของที่เก็บข้อมูล โดยเฉพาะอย่างยิ่งในโครงการที่มีอายุยาวนาน
48) Git Blame คืออะไร และใช้แก้จุดบกพร่องอย่างไร
git blame ระบุว่าคอมมิทและผู้เขียนคนใดแก้ไขบรรทัดสุดท้ายของไฟล์แต่ละบรรทัด
ตัวอย่างคำสั่ง:
git blame app.py
ใช้กรณี:
- การติดตามการแนะนำจุดบกพร่อง
- ระบุความเป็นเจ้าของของส่วนต่างๆ ของโค้ด
- การตรวจสอบการเปลี่ยนแปลงเพื่อความรับผิดชอบ
ตัวอย่าง: หากฟังก์ชันเริ่มล้มเหลวหลังจากการอัปเดตล่าสุด git blame สามารถระบุผู้กระทำการและนักพัฒนาที่ทำการเปลี่ยนแปลงได้อย่างชัดเจน ช่วยให้แก้ไขจุดบกพร่องได้รวดเร็วยิ่งขึ้น
49) ความแตกต่างระหว่าง Fork และ Cloning ใน Git คืออะไร?
| ปัจจัย | ส้อม | โคลน |
|---|---|---|
| คำนิยาม | สำเนาของที่เก็บข้อมูลภายใต้บัญชีของคุณบนบริการโฮสติ้ง | สำเนาท้องถิ่นของที่เก็บข้อมูล |
| สถานที่ | ฝั่งเซิร์ฟเวอร์ (เช่น GitHub) | เครื่องของนักพัฒนา |
| ใช้กรณี | การมีส่วนร่วมในโครงการอื่น ๆ | การพัฒนาท้องถิ่น |
| ความสัมพันธ์ | เชื่อมต่อผ่านคำขอดึง | ซิงค์โดยตรงกับรีโมท |
ตัวอย่าง: เมื่อมีส่วนสนับสนุนโครงการโอเพนซอร์ส คุณจะทำการฟอร์กที่เก็บข้อมูล ทำการเปลี่ยนแปลงในเครื่องหลังจากโคลน และส่งคำขอการดึงเพื่อตรวจสอบ
50) ข้อผิดพลาด Git ที่พบบ่อยที่สุดคืออะไร และจะหลีกเลี่ยงได้อย่างไร?
| ผิดพลาด | Descriptไอออน | การป้องกัน |
|---|---|---|
| การยืนยันข้อมูลที่ละเอียดอ่อน | รวมความลับหรือข้อมูลประจำตัว | ใช้ .gitignore หรือ GitGuardian |
| การบังคับผลักไปยังสาขาที่ใช้ร่วมกัน | เขียนทับงานของผู้อื่น | ใช้ --force-with-lease |
| คอมมิตไบนารีขนาดใหญ่ | ทำให้ประสิทธิภาพการทำงานของ repo ช้าลง | ใช้ Git LFS |
| ข้ามการตรวจสอบโค้ด | นำไปสู่คุณภาพที่ไม่ดี | ใช้คำขอดึง |
| การละเว้นความขัดแย้งในการรีเบส | ก่อให้เกิดความวุ่นวายในการรวมตัว | แก้ไขข้อขัดแย้งอย่างรอบคอบก่อนผลักดัน |
ตัวอย่าง: นักพัฒนาดันโดยไม่ได้ตั้งใจ .env ไฟล์ที่มีข้อมูลประจำตัวอาจเปิดเผยข้อมูลที่ละเอียดอ่อนได้ ซึ่งเราสามารถหลีกเลี่ยงได้ด้วย .gitignore กฎและข้อกำหนดก่อนการคอมมิท
🔍 คำถามสัมภาษณ์ GIT ยอดนิยมพร้อมสถานการณ์จริงและคำตอบเชิงกลยุทธ์
1) Git คืออะไร และแตกต่างจากระบบควบคุมเวอร์ชันอื่นอย่างไร
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการประเมินความเข้าใจของคุณเกี่ยวกับพื้นฐานของ Git และข้อดีเหนือระบบรวมศูนย์
ตัวอย่างคำตอบ: Git คือระบบควบคุมเวอร์ชันแบบกระจายที่ช่วยให้นักพัฒนาสามารถติดตามการเปลี่ยนแปลงในโค้ดเบสและทำงานร่วมกันได้อย่างมีประสิทธิภาพ ต่างจากระบบรวมศูนย์อย่าง SVN ตรงที่ Git ช่วยให้นักพัฒนาทุกคนมีสำเนาของคลังเก็บ (repository) ฉบับเต็ม รวมถึงประวัติการใช้งานด้วย โครงสร้างนี้รองรับการทำงานแบบออฟไลน์ การทำงานที่รวดเร็วขึ้น และความสามารถในการแยกสาขาและผสานรวมที่ดีขึ้น
2) คุณสามารถอธิบายความแตกต่างระหว่าง git fetch, git pull และ git merge ได้หรือไม่?
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์กำลังทดสอบความรู้ของคุณเกี่ยวกับคำสั่ง Git ทั่วไปและวัตถุประสงค์ของคำสั่งเหล่านั้น
ตัวอย่างคำตอบ: git fetch ดาวน์โหลดข้อมูลใหม่จากที่เก็บข้อมูลระยะไกลแต่ไม่รวมเข้าในสาขาปัจจุบันของคุณ git pull ดำเนินการดึงข้อมูลตามด้วยการรวมอัตโนมัติโดยบูรณาการข้อมูลใหม่ git merge ใช้เพื่อรวมการเปลี่ยนแปลงจากสาขาหนึ่งไปยังอีกสาขาหนึ่งด้วยตนเองหลังจากดึงข้อมูลอัปเดต
3) อธิบายสถานการณ์ที่คุณต้องแก้ไขข้อขัดแย้งในการผสาน คุณจัดการกับมันอย่างไร
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการทราบเกี่ยวกับทักษะการแก้ไขข้อขัดแย้งและความสามารถในการจัดการเวิร์กโฟลว์การทำงานร่วมกันของคุณ
ตัวอย่างคำตอบ: ในบทบาทสุดท้ายของผม เรามักจะทำงานบนสาขาที่ใช้ร่วมกัน ซึ่งบางครั้งนำไปสู่ความขัดแย้งในการรวมสาขา เมื่อผมเจอปัญหาแบบนี้ ผมจึงใช้ git status เพื่อระบุไฟล์ที่ขัดแย้งกันและตรวจสอบทั้งสองเวอร์ชันเพื่อตัดสินใจว่าจะเก็บการเปลี่ยนแปลงใดไว้ หลังจากแก้ไขและทดสอบไฟล์แล้ว ฉันได้ทำเครื่องหมายว่าความขัดแย้งได้รับการแก้ไขแล้วและยืนยันการเปลี่ยนแปลง ฉันยังสื่อสารกับทีมเพื่อหลีกเลี่ยงปัญหาที่คล้ายกันในอนาคตโดยการปรับปรุงแนวทางปฏิบัติในการจัดการสาขา
4) คุณใช้กลยุทธ์การแยกสาขาใน Git ในการจัดการโครงการอย่างไร
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการดูว่าคุณเข้าใจเวิร์กโฟลว์ที่มีโครงสร้าง เช่น Git Flow หรือการพัฒนาแบบ Trunk หรือไม่
ตัวอย่างคำตอบ: โดยทั่วไปฉันใช้กลยุทธ์ Git Flow ที่ประกอบด้วย main, developและสาขาคุณลักษณะ สาขาคุณลักษณะจะถูกสร้างขึ้นสำหรับงานใหม่แต่ละงาน และรวมเข้าเป็น develop หลังจากเสร็จสิ้นแล้วจึงทดสอบก่อนรวมเข้า mainวิธีการนี้ช่วยให้มั่นใจถึงการบูรณาการที่ควบคุมได้และรอบการปล่อยที่สะอาด
5) คุณจะดำเนินการอย่างไรหากคุณส่งข้อมูลสำคัญไปยังที่เก็บข้อมูล Git โดยไม่ได้ตั้งใจ?
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์กำลังประเมินความสามารถของคุณในการตอบสนองต่อปัญหาความปลอดภัยหรือการปฏิบัติตามข้อกำหนดอย่างมีประสิทธิผล
ตัวอย่างคำตอบ: อันดับแรก ฉันจะลบไฟล์ที่ละเอียดอ่อนโดยใช้ git rm --cached และยืนยันการเปลี่ยนแปลง ต่อไปฉันจะใช้เครื่องมือเช่น git filter-branch or BFG Repo-Cleaner เพื่อลบข้อมูลออกจากประวัติ สุดท้ายนี้ ฉันจะหมุนเวียนข้อมูลประจำตัวที่เปิดเผยและแจ้งให้ผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้องทราบเพื่อป้องกันความเสี่ยงที่อาจเกิดขึ้น
6) คุณจะมั่นใจได้อย่างไรว่าโค้ดมีความสอดคล้องกันเมื่อนักพัฒนาหลายคนทำการคอมมิทพร้อมๆ กัน?
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการทำความเข้าใจว่าคุณรักษาความสมบูรณ์ของโค้ดในสภาพแวดล้อมการทำงานร่วมกันได้อย่างไร
ตัวอย่างคำตอบ: ในงานก่อนหน้านี้ของผม เราได้กำหนดนโยบายที่กำหนดให้ทุกคอมมิตต้องผ่าน Pull Request และการตรวจสอบโค้ด การตรวจสอบ CI อัตโนมัติช่วยให้มั่นใจได้ว่ามีเพียงโค้ดที่ผ่านการทดสอบและตรวจสอบแล้วเท่านั้นที่ถูกผสานรวมเข้าด้วยกัน วิธีนี้ช่วยรักษาคุณภาพและความสอดคล้องกันในทุกสาขา
7) คุณจะย้อนกลับการคอมมิตที่ถูกผลักไปยังสาขาที่แชร์แล้วได้อย่างไร
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการทราบว่าคุณเข้าใจวิธีจัดการข้อผิดพลาดในที่เก็บข้อมูลที่ใช้ร่วมกันอย่างปลอดภัยหรือไม่
ตัวอย่างคำตอบ: วิธีที่ปลอดภัยที่สุดคือการใช้ git revert <commit_id>ซึ่งจะสร้างคอมมิตใหม่ที่ยกเลิกการเปลี่ยนแปลงจากคอมมิตที่ระบุ วิธีนี้จะช่วยรักษาประวัติโครงการและหลีกเลี่ยงการรบกวนนักพัฒนารายอื่น ซึ่งแตกต่างจาก git resetซึ่งจะเขียนประวัติศาสตร์ใหม่
8) บอกฉันเกี่ยวกับเวลาที่คุณต้องจัดการหลายสาขาสำหรับรุ่นที่แตกต่างกัน
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการข้อมูลเชิงลึกเกี่ยวกับความสามารถของคุณในการจัดการกับความซับซ้อนในการควบคุมเวอร์ชัน
ตัวอย่างคำตอบ: ในบทบาทก่อนหน้าของผม เราดูแลเวอร์ชันที่เผยแพร่หลายเวอร์ชันให้กับลูกค้า ผมใช้ Release Branch แยกกันสำหรับแต่ละเวอร์ชัน และแก้ไขจุดบกพร่องที่สำคัญโดยใช้ Cherry-pick วิธีนี้ช่วยให้มั่นใจได้ว่าการอัปเดตจะถูกนำมาใช้อย่างสม่ำเสมอโดยไม่เกิดปัญหาการถดถอยในเวอร์ชันใหม่
9) คุณจัดการกับที่เก็บข้อมูลขนาดใหญ่ที่มีผู้สนับสนุนจำนวนมากเพื่อให้ประสิทธิภาพการทำงานอยู่ในระดับที่เหมาะสมที่สุดได้อย่างไร
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์กำลังประเมินความรู้ของคุณในการปรับขนาด Git อย่างมีประสิทธิภาพ
ตัวอย่างคำตอบ: ฉันสนับสนุนการโคลนนิ่งแบบตื้น (--depth) เพื่อการเข้าถึงและใช้งานได้รวดเร็วยิ่งขึ้น .gitignore เพื่อแยกไฟล์ที่ไม่จำเป็นออก เรายังตัดไฟล์เก่าออกเป็นประจำ และใช้ Git LFS (Large File Storage) สำหรับทรัพยากรไบนารี ขั้นตอนเหล่านี้ช่วยให้ที่เก็บมีประสิทธิภาพและจัดการได้ง่าย
10) อธิบายสถานการณ์ที่คุณต้องดีบักปัญหา Git ที่ทำให้การพัฒนาหยุดชะงัก คุณมีแนวทางอย่างไร
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการดูทักษะการคิดวิเคราะห์และการแก้ไขปัญหาของคุณ
ตัวอย่างคำตอบ: ในตำแหน่งก่อนหน้านี้ ประวัติสาขาของสมาชิกในทีมเสียหายเนื่องจากการรีเบสที่ผิดพลาด ฉันได้ตรวจสอบโดยใช้ git log และ git reflog เพื่อติดตามปัญหา จากนั้น ฉันจึงคืนค่าคอมมิทที่ถูกต้องโดยใช้ git cherry-pick และมั่นใจว่าสาขาในพื้นที่ของทุกคนได้รับการซิงค์กับเวอร์ชันระยะไกลที่กำหนดไว้แล้ว วิธีนี้ช่วยป้องกันการหยุดชะงักเพิ่มเติมและรักษาประสิทธิภาพการทำงานของทีม
