คำถาม Git ในการสัมภาษณ์งาน: 25 ข้อพร้อมคำตอบ

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

คำถามเรียงจากพื้นฐานไปยังขั้นสูง เมื่อตอบในการสัมภาษณ์ ควรยกตัวอย่างสั้น ๆ จากประสบการณ์ถ้าทำได้ ซึ่งมีค่ากว่าการท่องเอกสาร

คำถามพื้นฐาน

1. Git คืออะไร และระบบควบคุมเวอร์ชันแบบกระจายต่างจากแบบรวมศูนย์อย่างไร?

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

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

2. การทำงานกับ Git ประกอบด้วยพื้นที่สามส่วนอะไรบ้าง?

โฟลเดอร์งาน (ไฟล์บนดิสก์) อินเด็กซ์หรือ staging area (สแนปชอตที่เตรียมไว้สำหรับคอมมิตถัดไป) และรีโพซิทอรีในเครื่อง (โฟลเดอร์ .git ที่เก็บประวัติ) git add ย้ายการเปลี่ยนแปลงจากโฟลเดอร์งานเข้าอินเด็กซ์ และ git commit ย้ายจากอินเด็กซ์เข้ารีโพซิทอรี

จุดเพิ่มเติมที่ดีคือพูดถึงพื้นที่ที่สี่ คือรีโมตรีโพซิทอรี พร้อมคำสั่ง git push และ git fetch ที่ทำงานกับมัน

3. ทำไมต้องมีอินเด็กซ์ ในเมื่อคอมมิตได้โดยตรง?

อินเด็กซ์ช่วยให้สร้างคอมมิตได้อย่างตั้งใจ เช่น จากไฟล์ที่แก้ไขสิบไฟล์ คุณคอมมิตสามไฟล์ที่เกี่ยวข้องกับงานเดียวกัน และเก็บส่วนที่เหลือไว้ก่อน ด้วย git add -p คุณเลือกได้แม้กระทั่งส่วนย่อยภายในไฟล์

นี่คือพื้นฐานของคอมมิตแบบ atomic คือหนึ่งคอมมิตต่อหนึ่งการเปลี่ยนแปลงเชิงตรรกะ ประวัติแบบนี้อ่านง่าย รีวิวง่าย ย้อนด้วย revert ได้ และย้ายด้วย cherry-pick ได้

4. คอมมิตคืออะไรในเชิงโครงสร้างภายในของ Git?

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

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

5. บรานช์และ HEAD คืออะไร?

บรานช์คือตัวชี้ที่เคลื่อนที่ได้ไปยังคอมมิต เป็นไฟล์ใน .git/refs/heads/ ที่มีแฮชอยู่ข้างใน การสร้างบรานช์จึงทำได้ทันทีและไม่ได้คัดลอกอะไร เมื่อมีคอมมิตใหม่ ตัวชี้ของบรานช์ปัจจุบันจะขยับไปยังคอมมิตนั้น

HEAD คือตัวชี้ว่าคุณอยู่ที่ไหนตอนนี้ โดยปกติชี้ไปยังบรานช์ (ref: refs/heads/main) หากสลับไปยังคอมมิตหรือแท็กโดยตรง HEAD จะชี้ไปยังคอมมิตนั้น ซึ่งคือสถานะ detached HEAD

6. Detached HEAD คืออะไร และมีอันตรายอย่างไร?

เป็นสถานะที่ HEAD ชี้ไปยังคอมมิตแทนที่จะเป็นบรานช์ เช่นหลัง git switch --detach v1.0 หรือ git checkout a1b2c3d คุณดูโค้ดและคอมมิตได้ แต่คอมมิตใหม่จะไม่อยู่ในบรานช์ใดเลย

หากสลับไปยังบรานช์อื่นหลังจากนั้น คอมมิตเหล่านั้นจะเข้าไม่ถึง และในที่สุดตัวเก็บขยะจะลบทิ้ง เพื่อเก็บงานไว้ให้สร้างบรานช์: git switch -c fix-from-detached หากออกไปแล้ว แฮชจะหาเจอได้ใน git reflog

7. git fetch ต่างจาก git pull อย่างไร?

git fetch ดาวน์โหลดคอมมิตใหม่และอัปเดต remote-tracking branch เช่น origin/main แต่ไม่แตะบรานช์ในเครื่องหรือไฟล์ของคุณ git pull คือ fetch บวกการรวมผลลัพธ์ โดยค่าเริ่มต้นเป็น merge และหากใช้แฟล็ก --rebase หรือตั้ง pull.rebase=true จะเป็น rebase

นักพัฒนาที่มีประสบการณ์มักรัน fetch แยก ดู git log HEAD..origin/main แล้วจึงตัดสินใจว่าจะรวมการเปลี่ยนแปลงอย่างไร

8. .gitignore ทำงานอย่างไร และทำไมไฟล์ยังถูกติดตามทั้งที่ใส่ไว้แล้ว?

.gitignore กำหนดรูปแบบไฟล์ที่ Git ไม่ควรเสนอให้เพิ่ม เช่น dependency ผลลัพธ์การบิลด์ ล็อก และคอนฟิกในเครื่องที่มีความลับ กฎมีผลเฉพาะกับไฟล์ที่ยังไม่ถูกติดตาม

หากไฟล์ถูกคอมมิตไปแล้ว การใส่ในไฟล์นี้ไม่มีผล ต้องนำออกจากอินเด็กซ์แต่คงไว้บนดิสก์: git rm --cached config.local.php แล้วคอมมิตการลบนั้น ตรวจว่ากฎใดทำงานได้ด้วย git check-ignore -v พาธ

บรานช์ การรวม และ conflict

9. fast-forward merge คืออะไร?

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

แฟล็ก --no-ff บังคับให้สร้าง merge commit แม้ในกรณีนี้ ทำให้เห็นในประวัติว่ากลุ่มคอมมิตนั้นเป็นฟีเจอร์แยกต่างหาก ส่วนแฟล็ก --ff-only อนุญาตเฉพาะ fast-forward และปฏิเสธหากต้องการ merge จริง

10. conflict ของการ merge เกิดขึ้นอย่างไร และแก้อย่างไร?

conflict เกิดเมื่อทั้งสองบรานช์แก้บรรทัดเดียวกันของไฟล์ (หรือไฟล์ถูกลบในบรานช์หนึ่งและแก้ในอีกบรานช์) และ Git ตัดสินใจเองไม่ได้ Git จะหยุดการ merge และทำเครื่องหมายตำแหน่งด้วย <<<<<<<, =======, >>>>>>>

git status                 # รายการไฟล์ที่มี conflict
# แก้ไฟล์ โดยเก็บเวอร์ชันที่ถูกต้อง
git add app.js
git commit                 # สำหรับ merge; สำหรับ rebase ใช้ git rebase --continue

คำตอบที่ดีควรรวมการป้องกันด้วย เช่น บรานช์เล็ก ดึงจากบรานช์หลักบ่อย และตกลงเรื่องการจัดรูปแบบโค้ดร่วมกัน และรู้จัก git merge --abort หากต้องการถอยกลับ

11. merge กับ rebase ต่างกันอย่างไร?

merge รวมสองบรานช์โดยสร้าง merge commit ที่มีพาเรนต์สองตัว คอมมิตที่มีอยู่ไม่เปลี่ยน ประวัติสะท้อนการทำงานคู่ขนานอย่างตรงไปตรงมา rebase ย้ายคอมมิตของบรานช์คุณไปวางทับอีกบรานช์ โดยสร้างสำเนาของคอมมิตพร้อมแฮชใหม่ ประวัติจึงเป็นเส้นตรง

กฎทั่วไปคือ ใช้ rebase เพื่อจัดระเบียบบรานช์ในเครื่องของคุณก่อนเผยแพร่ และใช้ merge เพื่อรวมเข้าบรานช์ร่วม การ rebase คอมมิตที่เผยแพร่แล้วซึ่งคนอื่นกำลังทำงานต่อบนนั้น จะทำให้เกิดคอมมิตซ้ำและความสับสน

12. interactive rebase คืออะไร และใช้ทำอะไร?

git rebase -i HEAD~5 เปิดรายการห้าคอมมิตล่าสุด ซึ่งคุณเลือกการกระทำให้แต่ละคอมมิตได้ คือ pick เก็บไว้, reword แก้ข้อความ, edit หยุดเพื่อแก้ไข, squash และ fixup รวมเข้ากับคอมมิตก่อนหน้า, drop ลบ และสามารถสลับลำดับบรรทัดได้

สถานการณ์ทั่วไปคือ ก่อนเปิด pull request ให้เปลี่ยนคอมมิต "wip", "fix typo", "ฟิกซ์อีกนิด" ให้เป็นสองถึงสามคอมมิตที่มีความหมาย การใช้คู่กันได้ดีคือ git commit --fixup=<hash> แล้วตามด้วย git rebase -i --autosquash

13. squash merge คืออะไร และเมื่อไรควรเลือกใช้?

ใน squash merge คอมมิตทั้งหมดของบรานช์จะถูกบีบรวมเป็นคอมมิตเดียวในบรานช์ปลายทาง (git merge --squash หรือปุ่มบน GitHub/GitLab) บรานช์หลักจึงได้หนึ่งคอมมิตต่อหนึ่งฟีเจอร์

ข้อดีคือประวัติของ main สะอาด ข้อเสียคือรายละเอียดภายในฟีเจอร์หายไป และ Git ไม่นับบรานช์ต้นทางว่าถูก merge แล้ว ดังนั้น git branch -d จะปฏิเสธการลบโดยไม่มี -D

14. cherry-pick คืออะไร และเหมาะเมื่อไร?

git cherry-pick <hash> นำการเปลี่ยนแปลงของคอมมิตเดียวมาใช้กับบรานช์ปัจจุบัน สร้างคอมมิตใหม่ที่มีเนื้อหาเดิมแต่แฮชต่างกัน กรณีคลาสสิกคือการย้ายการแก้บั๊กจาก develop ไปยังบรานช์รีลีสหรือ hotfix

ไม่ควรใช้บ่อยเกินไป เพราะการแก้เดียวกันจะอยู่ในสองคอมมิต และอาจเกิด conflict เมื่อบรานช์ถูก merge ในภายหลัง แฟล็ก -x จะเพิ่มการอ้างอิงถึงคอมมิตต้นทางในข้อความ

การย้อนการเปลี่ยนแปลงและการกู้คืน

15. reset --soft, --mixed และ --hard ต่างกันอย่างไร?

โหมด	ตัวชี้บรานช์	อินเด็กซ์	โฟลเดอร์งาน
--soft	ขยับ	ไม่เปลี่ยน	ไม่เปลี่ยน
--mixed (ค่าเริ่มต้น)	ขยับ	รีเซ็ต	ไม่เปลี่ยน
--hard	ขยับ	รีเซ็ต	รีเซ็ต การแก้ไขหายไป

git reset --soft HEAD~3 มีประโยชน์เมื่อต้องการทำสามคอมมิตล่าสุดใหม่ให้เป็นคอมมิตเดียว ส่วน --hard อันตรายกับการแก้ไขที่ยังไม่คอมมิต แม้แต่ reflog ก็กู้คืนให้ไม่ได้

16. git revert ต่างจาก git reset อย่างไร?

reset ย้ายตัวชี้ของบรานช์กลับ ซึ่งเท่ากับเขียนประวัติใหม่ ส่วน revert สร้างคอมมิตใหม่ที่ยกเลิกการเปลี่ยนแปลงของคอมมิตที่ระบุ และไม่เขียนอะไรใหม่

ดังนั้นสำหรับคอมมิตที่เผยแพร่แล้วในบรานช์ร่วม คำตอบที่ถูกคือ revert: ประวัติของเพื่อนร่วมทีมไม่เสียหาย และการย้อนกลับเห็นได้ชัดในล็อก สำหรับ merge commit ต้องระบุพาเรนต์หลัก: git revert -m 1 <hash>

17. กู้คอมมิตหลังจาก git reset --hard โดยไม่ตั้งใจอย่างไร?

ผ่าน git reflog ซึ่งเก็บประวัติการเคลื่อนที่ของ HEAD และบรานช์ไว้ในเครื่อง (รายการปกติอยู่ได้ราว 90 วัน) หารายการก่อนคำสั่งที่พลาด แล้วย้อนกลับ:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# 9f8e7d6 HEAD@{1}: commit: เพิ่มการชำระเงิน
git reset --hard 9f8e7d6

ข้อควรระวัง reflog ช่วยได้เฉพาะสิ่งที่ถูกคอมมิตแล้ว การแก้ไขที่ไม่เคยเข้าคอมมิตหรือ stash เลยนั้น Git กู้คืนไม่ได้

18. ย้อนการแก้ไขในไฟล์และนำออกจากอินเด็กซ์อย่างไร?

คำสั่งสมัยใหม่คือ git restore app.js (กลับไปยังสถานะของอินเด็กซ์) และ git restore --staged app.js (นำออกจากอินเด็กซ์แต่คงการแก้ไขไว้) แบบเดิมใช้ git checkout -- app.js และ git reset HEAD app.js ซึ่งยังใช้งานได้

19. git stash คืออะไร และมีข้อควรระวังอะไรบ้าง?

git stash เก็บการเปลี่ยนแปลงที่ยังไม่คอมมิตไว้ชั่วคราวและล้างโฟลเดอร์งาน เช่น เพื่อสลับไปแก้ hotfix ด่วน แล้วคืนด้วย git stash pop หรือ apply

ข้อควรระวัง: โดยค่าเริ่มต้นไฟล์ที่ไม่ถูกติดตามจะไม่ถูกเก็บ (ต้องใช้ -u) เมื่อ pop อาจเกิด conflict และในกรณีนั้นรายการจะไม่ถูกลบออกจากลิสต์ และ stash ก็ถูกลืมได้ง่าย สำหรับงานที่ต้องทำต่อเนื่องนาน ควรคอมมิตลงบรานช์แยกแทน

คำถามขั้นสูงและการทำงานเป็นทีม

20. จะหาคอมมิตที่ทำให้ฟังก์ชันพังได้อย่างไร?

ด้วย git bisect ซึ่งเป็นการค้นหาแบบไบนารีในประวัติ คุณระบุคอมมิตที่เสียแน่นอนและคอมมิตที่ใช้ได้ Git จะพาคุณไปยังจุดกึ่งกลางของช่วง จนพบต้นเหตุภายใน log2(N) ขั้น

git bisect start
git bisect bad                 # เวอร์ชันปัจจุบันพัง
git bisect good v2.3.0         # ตรงนี้ยังทำงานได้
# ตรวจแล้วตอบ good/bad จนกว่า Git จะชี้คอมมิต
git bisect reset

หากมีสคริปต์ตรวจสอบ กระบวนการนี้อัตโนมัติได้ด้วย git bisect run npm test

21. ทำไม git push --force จึงอันตราย และควรใช้อะไรแทน?

--force เขียนทับบรานช์รีโมตด้วยเวอร์ชันของคุณ คอมมิตที่เพื่อนร่วมทีมได้ push ไปแล้วจะหายจากเซิร์ฟเวอร์ ปลอดภัยกว่าคือ git push --force-with-lease ซึ่งจะเขียนทับเฉพาะเมื่อบรานช์บนเซิร์ฟเวอร์ยังอยู่ในสถานะที่คุณเห็นครั้งล่าสุดตอน fetch

การ push แบบบังคับเป็นเรื่องปกติกับบรานช์ฟีเจอร์ของตัวเองหลัง rebase แต่กับ main หรือบรานช์ร่วมอื่น ๆ มักถูกห้ามด้วยการป้องกันบรานช์บนเซิร์ฟเวอร์

22. คุณรู้จัก workflow ของ Git แบบใดบ้าง?

GitHub Flow มีบรานช์หลักเดียวที่พร้อมดีพลอยเสมอ และบรานช์ฟีเจอร์สั้น ๆ ที่รวมผ่าน pull request หลังการรีวิวและ CI Git Flow มีบรานช์ main และ develop รวมถึง feature/*, release/* และ hotfix/* เหมาะกับผลิตภัณฑ์ที่มีรีลีสเป็นเวอร์ชัน Trunk-based development ทุกคนรวมเข้า trunk บ่อยมาก และงานที่ยังไม่เสร็จถูกซ่อนด้วย feature flag

คำตอบที่แข็งแรงอธิบายการเลือก เช่น สำหรับบริการเว็บที่ดีพลอยต่อเนื่อง Git Flow มักซับซ้อนเกินไป ส่วนไลบรารีที่รองรับหลายเวอร์ชันพร้อมกันคุ้มค่ากับมัน

23. pull request คืออะไร และตรวจอะไรบ้าง?

pull request (ใน GitLab เรียก merge request) คือคำขอรวมบรานช์ที่ต้องผ่านการรีวิวโค้ดและการตรวจอัตโนมัติของ CI ก่อนถูกรวม นี่เป็นฟีเจอร์ของแพลตฟอร์ม (GitHub, GitLab, Bitbucket) ไม่ใช่ของ Git เอง

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

24. คุณปฏิบัติตามหลักใดในการเขียนข้อความคอมมิต?

หัวข้อสั้น (ไม่เกิน 50–72 อักขระ) ใช้รูปคำสั่ง เช่น "เพิ่มการตรวจสอบอีเมล" จากนั้นบรรทัดว่างและเนื้อความที่อธิบาย "ทำไม" มากกว่า "อะไร" (สิ่งที่เปลี่ยนไปดูได้จากดิฟ) หลายทีมใช้ Conventional Commits เช่น feat:, fix:, docs:, refactor:

ข้อความแบบนี้ช่วยสร้าง changelog ค้นหาได้เร็วด้วย git log --grep และเข้าใจเหตุผลของการเปลี่ยนแปลงได้แม้ผ่านไปหลายปี

25. หากคุณ push รหัสผ่านเข้าไปในรีโพซิทอรีโดยไม่ตั้งใจ จะทำอย่างไร?

ขั้นแรกคือเพิกถอนและสร้างความลับใหม่ เพราะมันถูกเปิดเผยแล้ว แม้จะลบภายในหนึ่งนาที (โคลน ฟอร์ก และแคชยังคงมี) จากนั้นนำไฟล์ออกจากการติดตาม เพิ่มใน .gitignore และหากจำเป็นให้ล้างประวัติด้วยเครื่องมืออย่าง git filter-repo ตามด้วย force push และแจ้งทีม

ผู้สัมภาษณ์ดูลำดับความสำคัญ ผู้สมัครที่เริ่มด้วยการเขียนประวัติใหม่และลืมการหมุนเวียนคีย์ ตอบผิด

วิธีเตรียมตัวสำหรับคำถาม Git

วิธีที่เชื่อถือได้ที่สุดคือไม่ท่องคำตอบ แต่ทดลองทุกสถานการณ์ด้วยมือในรีโพทดสอบ สร้าง conflict และแก้ไข ทำ reset --hard แล้วกู้คืนด้วย reflog บีบอัดคอมมิตด้วย interactive rebase ในการสัมภาษณ์ Git มักมีงานปฏิบัติ หรือให้วาดกราฟคอมมิตก่อนและหลังคำสั่ง หากคุณเคยทำเองมาแล้ว คำตอบจะออกมาได้ง่าย

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

สรุป

การสัมภาษณ์เรื่อง Git เกือบทั้งหมดวนอยู่กับสามหัวข้อ คือ โมเดลข้อมูล (คอมมิต บรานช์ HEAD อินเด็กซ์) การรวมการเปลี่ยนแปลง (merge, rebase, conflict, fetch และ pull) และการย้อนอย่างปลอดภัย (reset, revert, reflog) เพิ่มความเข้าใจเรื่อง workflow ของทีมและ pull request คุณก็ครอบคลุมคำถามส่วนใหญ่ได้ สถานการณ์เหล่านี้รวมถึงการทำงานเป็นทีมและเครื่องมือขั้นสูง เราฝึกอย่างลงมือทำในหลักสูตร Git