ข้ามไปยังเนื้อหาหลัก

25 คำถามสัมภาษณ์ Git ที่พบบ่อยสำหรับทุกระดับ พร้อมคำตอบ

ทบทวนคำสั่ง แนวคิด และการเปรียบเทียบใน Git ที่มักถูกถามในการสัมภาษณ์ด้านเทคนิค
อัปเดตแล้ว 2 มิ.ย. 2569  · 13 นาที อ่าน

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

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

คำถามสัมภาษณ์ Git ระดับพื้นฐาน

หากเพิ่งเริ่มต้นใช้ Git เป็นไปได้ว่าคำถามสัมภาษณ์พื้นฐานจะเกี่ยวกับแนวคิดและการใช้งานระดับเริ่มต้น หากต้องการทบทวน แนะนำให้ดูคอร์ส Introduction to Git ของ DataCamp

Git repository คืออะไร?

Git repository ใช้เก็บไฟล์ของโครงการและประวัติการแก้ไข ช่วยให้ควบคุมเวอร์ชันด้วยการติดตามการเปลี่ยนแปลงตามกาลเวลา สามารถอยู่ในเครื่องภายในโฟลเดอร์บนอุปกรณ์ของคุณ หรืออยู่บนแพลตฟอร์มออนไลน์อย่าง GitHub สิ่งนี้ช่วยให้ทำงานร่วมกัน ย้อนกลับไปยังเวอร์ชันก่อนหน้า และจัดการการพัฒนาโครงการอย่างมีประสิทธิภาพด้วยคำสั่งอย่าง commit, push และ pull

Git ทำงานอย่างไร?

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

git add คืออะไร?

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

git push คืออะไร?

คำสั่ง git push ใช้สำหรับอัปโหลดเนื้อหา repository ในเครื่องขึ้นไปยัง repository ระยะไกล ทำการส่งต่อการเปลี่ยนแปลงที่ commit แล้วจาก repository ในเครื่องไปยัง repository บนเซิร์ฟเวอร์ เช่น GitHub หรือ GitLab คำสั่งนี้ช่วยให้ทำงานร่วมกันได้ โดยเปิดโอกาสให้ผู้ใช้แบ่งปันการเปลี่ยนแปลงกับผู้อื่นในโครงการเดียวกัน

ดูข้อมูลเพิ่มเติมเกี่ยวกับ Git push และ pull ได้ในบทช่วยสอนแยกต่างหากของเรา

git status คืออะไร?

คำสั่ง git status แสดงสถานะปัจจุบันของ repository ใน Git ให้ข้อมูลว่าไฟล์ใดถูกแก้ไขแล้ว ไฟล์ใดอยู่ใน staging เพื่อ commit ถัดไป และไฟล์ใดที่ยังไม่ถูกติดตาม ช่วยให้ผู้ใช้ติดตามความคืบหน้าของงานและระบุการเปลี่ยนแปลงที่ต้อง commit หรือ staging

commit ใน Git คืออะไร?

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

แต่ละ commit จะมีตัวระบุเฉพาะ ช่วยให้ติดตามประวัติการเปลี่ยนแปลงใน repository ได้ Commit มีบทบาทสำคัญในการควบคุมเวอร์ชัน เพราะช่วยให้ย้อนกลับไปยังสถานะก่อนหน้า ตรวจทานประวัติการเปลี่ยนแปลง และทำงานร่วมกับผู้อื่นด้วยการแบ่งปันอัปเดต

Git cheat sheet

ดู Git Cheat Sheet ของ DataCamp เพื่อช่วยเตรียมตัวสัมภาษณ์

branching ใน Git คืออะไร?

Branching คือแนวทางการแยกจากสายพัฒนาหลัก (โดยทั่วไปเรียกว่า main และเดิมเรียกว่า master) เพื่อพัฒนาฟีเจอร์ใหม่ แก้ไขข้อบกพร่อง หรือทดลองแนวคิด โดยไม่กระทบต่อฐานโค้ดหลัก ช่วยให้สายการพัฒนาคู่ขนานหลายสายอยู่ร่วมกันใน repository เดียว

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

conflict ใน Git คืออะไร?

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

วิธีแก้ conflict ให้เปิดไฟล์ที่ได้รับผลกระทบ — Git จะทำเครื่องหมายส่วนที่ขัดแย้งด้วยตัวคั่น <<<<<<<, ======= และ >>>>>>> จากนั้นแก้ไขไฟล์เพื่อเก็บเวอร์ชันที่ถูกต้อง ลบตัวคั่นออก แล้ว:

git add <resolved-file>
git commit
เครื่องมืออย่าง VS Code, IntelliJ และ git mergetool ช่วยให้ขั้นตอนนี้เป็นภาพและทำได้ง่ายขึ้น

merge ใน Git คืออะไร?

การผสาน (merge) เป็นปฏิบัติการพื้นฐานใน Git ที่ช่วยอำนวยความร่วมมือและการรวมการเปลี่ยนแปลงข้ามสาขาในโครงการ กล่าวคือ การ merge คือกระบวนการรวมการเปลี่ยนแปลงจากสาขาต่างๆ เข้าสู่สาขาเดียว โดยทั่วไปคือสาขาหลัก (เช่น master หรือ main)

การ merge จะรวมการเปลี่ยนแปลงจากสาขาหนึ่งเข้ากับอีกสาขาหนึ่ง ส่งผลให้เกิด commit ใหม่ที่ผสานประวัติของทั้งสองสาขา สามารถเรียนรู้เพิ่มเติมเกี่ยวกับ วิธีแก้ปัญหา merge conflict ใน Git ได้จากบทช่วยสอนแยกต่างหากของเรา

คำถามสัมภาษณ์ Git ระดับกลาง

remote ใน Git คืออะไร?

Remote คือ repository ที่โฮสต์อยู่บนเซิร์ฟเวอร์หรือคอมพิวเตอร์เครื่องอื่น เพื่อใช้ทำงานร่วมกันและแบ่งปันโค้ดกับผู้อื่น เป็นศูนย์กลางที่นักพัฒนาสามารถ push การเปลี่ยนแปลงจากเครื่องตนเอง และ pull การเปลี่ยนแปลงที่คนอื่นทำไว้

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

จะย้อน commit ที่ push และเปิดสาธารณะไปแล้วได้อย่างไร?

สามารถใช้คำสั่ง git revert <commit-hash> เพื่อย้อน commit ที่ได้ push และเปิดสาธารณะไปแล้ว

ขั้นตอนโดยละเอียดมีดังนี้:

1. ระบุ commit ที่ต้องการย้อนกลับด้วยการหา commit hash สามารถใช้คำสั่ง git log เพื่อดูประวัติ commit และค้นหา commit hash ที่ต้องการย้อน

2. เมื่อได้ commit hash แล้ว ใช้คำสั่ง git revert ตามด้วย commit hash เพื่อสร้าง commit ใหม่ที่ลบล้างการเปลี่ยนแปลงที่ commit ดังกล่าวนำเข้ามา ตัวอย่าง:

git revert <commit-hash>

3. Git จะเปิดตัวแก้ไขข้อความเพื่อเขียนข้อความ commit สำหรับการ revert สามารถแก้ไขได้ตามต้องการ แล้วบันทึกและปิดตัวแก้ไข

4. หลังจากบันทึกข้อความ commit แล้ว Git จะสร้าง commit ใหม่ที่ลบล้างการเปลี่ยนแปลงที่ commit เดิมนำเข้ามา และเพิ่ม commit ใหม่นี้ลงในประวัติ ทำให้เกิดการย้อนการเปลี่ยนแปลงของ commit ต้นฉบับ

5. สุดท้าย ให้ push commit ใหม่นี้ขึ้น repository ระยะไกลเพื่อเผยแพร่การ revert ด้วยคำสั่งต่อไปนี้:

git push origin <branch-name> 

การใช้ git revert จะสร้าง commit ใหม่ที่ลบล้างการเปลี่ยนแปลงของ commit เดิม โดยไม่แก้ไขประวัติ commit วิธีนี้ปลอดภัยกว่า git reset หรือ git amend ที่อาจแก้ไขประวัติ commit และทำให้เกิดปัญหากับผู้ร่วมงานที่ได้ pull การเปลี่ยนแปลงไปแล้ว

git stash คืออะไร?

git stash เป็นคำสั่งที่ใช้เก็บการเปลี่ยนแปลงชั่วคราวใน working directory ที่ยังไม่พร้อมสำหรับการ commit ช่วยให้นักพัฒนาบันทึกการแก้ไขไว้โดยไม่ต้อง commit ลง repository

การ stash มีประโยชน์เมื่อสลับสาขา แต่ไม่ต้องการ commit หรือสูญเสียการเปลี่ยนแปลง หลังจากนั้นสามารถนำการเปลี่ยนแปลงที่ stash ไว้มาปรับใช้กับ working directory หรือ pop ออกจากกอง stash เพื่อทำงานต่อได้

git reflog คืออะไร?

git reflog เป็นคำสั่งที่ใช้ดู reference log ซึ่งบันทึกการเปลี่ยนแปลงของตัวชี้ HEAD และประวัติของ commit ที่ถูก checkout ใน repository โดยแสดงรายการการกระทำล่าสุดตามลำดับเวลา รวมถึง commit, checkout, merge และ reset

reflog มีประโยชน์ในการกู้คืน commit หรือสาขาที่หายไป และช่วยทำความเข้าใจลำดับการกระทำที่เกิดขึ้นใน repository

จะทำให้สาขา Git ที่มีอยู่ติดตามสาขาระยะไกลได้อย่างไร?

เพื่อให้สาขาที่มีอยู่ติดตามสาขาระยะไกล สามารถใช้คำสั่ง git branch พร้อมตัวเลือก --set-upstream-to หรือ -u ตามด้วยชื่อสาขาระยะไกล

ไวยากรณ์จะมีลักษณะดังนี้:

git branch --set-upstream-to=<remote-name>/<branch-name>

หรือ

git branch -u <remote-name>/<branch-name>

คำถามสัมภาษณ์ Git ระดับสูง

จะจัดการการตั้งค่าหลายแบบสำหรับโครงการต่างๆ ใน Git ได้อย่างไร?

เพื่อจัดการการตั้งค่าหลายแบบ ให้ใช้คำสั่ง git config ร่วมกับแฟล็ก --global, --system หรือ --local เพื่อปรับการตั้งค่าคอนฟิกในระดับต่างๆ หรือใช้ includeIf ในไฟล์คอนฟิกของ Git เพื่อรวมการตั้งค่าเฉพาะตามเส้นทางของ repository

จะจัดการไฟล์ขนาดใหญ่ด้วย Git ได้อย่างไร?

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

git submodule ใช้ทำอะไร และจะอัปเดตอย่างไร?

คำสั่ง git submodule ใช้จัดการการพึ่งพาภายนอกภายใน Git repository ช่วยให้รวม repository ภายนอกเป็น submodule ภายใน repository หลัก เหมาะเมื่อคุณต้องการรวมโค้ดจากแหล่งภายนอก แต่ยังคงแยกจากฐานโค้ดหลักของโครงการ

ขั้นตอนการอัปเดต submodule ใน Git มีดังนี้:

  1. ไปยังไดเรกทอรีของ submodule ภายใน repository หลัก

  2. ใช้ git fetch เพื่อดึงการเปลี่ยนแปลงล่าสุดจาก repository ระยะไกลของ submodule

  3. หากต้องการอัปเดตไปยัง commit ล่าสุดบนสาขาที่ submodule ติดตามอยู่ ให้ใช้ git pull

  4. หรือหากต้องการอัปเดตไปยัง commit หรือสาขาเฉพาะ ให้ใช้ git checkout ตามด้วย commit hash หรือชื่อสาขาที่ต้องการ

  5. เมื่ออัปเดต submodule ไปยังสถานะที่ต้องการแล้ว ต้อง commit การเปลี่ยนแปลงใน repository หลักเพื่อสะท้อนสถานะ submodule ที่อัปเดต

git cherry-pick คืออะไร และจะใช้เมื่อใด?

git cherry-pick ช่วยนำ commit เฉพาะจากสาขาหนึ่งไปใช้บนอีกสาขาหนึ่ง โดยไม่ต้อง merge ทั้งสาขา

git cherry-pick <commit-hash>
 
กรณีใช้งานที่พบบ่อยคือการ back-port แก้ไขบั๊ก สมมติว่ามีการแก้บั๊กบนสาขา main แต่ต้องการการแก้ไขนั้นในสาขา release ด้วย — สามารถ cherry-pick เฉพาะ commit นั้นได้ แทนที่จะ merge ทั้ง main เข้าสู่ release.

ยังมีประโยชน์เมื่อเผลอ commit ไปยังสาขาที่ไม่ถูกต้อง: ให้ cherry-pick ไปยังสาขาที่ถูกต้อง แล้วค่อย revert ออกจากสาขาที่ไม่ควรมี

git bisect คืออะไร และใช้ทำอะไร?

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

git bisect start
git bisect bad                # current commit has the bug
git bisect good <commit-hash> # this older commit was fine
# Git checks out a commit in between; you test it, then:
git bisect good   # or git bisect bad
# repeat until Git identifies the first bad commit
git bisect reset  # return to original state when done

วิธีนี้เร็วกว่าการค้นหาด้วยตนเองมากใน repository ขนาดใหญ่ที่มี commit หลายร้อยรายการ

Git hooks คืออะไร และใช้อย่างไร?

Git hooks คือสคริปต์ที่ทำงานอัตโนมัติในจุดต่างๆ ของเวิร์กโฟลว์ Git อยู่ในไดเรกทอรี .git/hooks/ ของ repository และเขียนด้วยภาษาสคริปต์ใดๆ ก็ได้

มีสองประเภท:

  • Client-side hooks ทำงานบนเครื่องของคุณเอง — ตัวอย่างเช่น pre-commit (ทำงานก่อนสร้าง commit) หรือ commit-msg (ตรวจสอบรูปแบบข้อความ commit)

  • Server-side hooks ทำงานบนเซิร์ฟเวอร์ระยะไกล — ตัวอย่างเช่น pre-receive (ทำงานก่อนรับ commit ที่ถูก push)

กรณีใช้งานที่พบบ่อยคือใช้ hook แบบ pre-commit เพื่อรัน linter หรือชุดทดสอบโดยอัตโนมัติก่อนอนุญาตให้ commit ช่วยบังคับใช้มาตรฐานคุณภาพโค้ดในทั้งทีม

โปรดทราบว่า hook จะไม่ถูกคัดลอกเมื่อทำการ clone repository ดังนั้นทีมที่พึ่งพา hook มักจะแชร์ผ่านสคริปต์แยกต่างหากหรือเครื่องมืออย่าง pre-commit (แพ็กเกจ Python)

คำถามเกี่ยวกับแนวคิด Git ที่มักสับสน

ความแตกต่างระหว่าง git fetch และ git pull คืออะไร?

ความแตกต่างหลักระหว่าง git fetch และ git pull อยู่ที่สิ่งที่ทำและวิธีอัปเดต repository ในเครื่อง

คำสั่ง git fetch จะดึงการเปลี่ยนแปลงจาก repository ระยะไกลมายังเครื่อง โดยอัปเดตสาขาติดตามระยะไกล (เช่น origin/master) ในเครื่องให้สะท้อนสถานะของระยะไกล แต่จะไม่อัปเดต working directory หรือ merge การเปลี่ยนแปลงเข้าสู่สาขาปัจจุบัน นั่นหมายความว่าหลังจาก fetch แล้ว สามารถตรวจทานการเปลี่ยนแปลงจากระยะไกลได้โดยไม่กระทบงานในเครื่อง

คำสั่ง git pull ก็จะดึงการเปลี่ยนแปลงจาก repository ระยะไกลเช่นกัน แต่จะไปไกลกว่านั้นด้วยการ fetch และ merge เข้าสู่สาขาปัจจุบันในขั้นตอนเดียว กล่าวคือเป็นการทำ git fetch ตามด้วย git merge เพื่อรวมการเปลี่ยนแปลงจากระยะไกลเข้าสู่สาขาปัจจุบัน

git reset ทำอะไร?

คำสั่ง git reset ใช้รีเซ็ต HEAD ปัจจุบันไปยังสถานะที่ระบุ ซึ่งหมายความว่าสามารถใช้ย้อนการเปลี่ยนแปลง นำไฟล์ออกจาก staging หรือย้ายตัวชี้ HEAD ไปยัง commit อื่น โปรดทราบว่า git reset มีโหมดหลัก 3 แบบ:

  • --soft: รีเซ็ตตัวชี้ HEAD ไปยัง commit ที่ระบุ โดยคงการเปลี่ยนแปลงไว้ใน staging ไฟล์ยังคงเป็นสถานะแก้ไขใน working directory ทำให้สามารถ commit ใหม่ได้
  • --mixed: รีเซ็ตตัวชี้ HEAD ไปยัง commit ที่ระบุ โดยนำการเปลี่ยนแปลงออกจาก staging ไฟล์ยังคงเป็นสถานะแก้ไขใน working directory แต่ไม่ได้ถูก staging เพื่อ commit
  • --hard: รีเซ็ตตัวชี้ HEAD ไปยัง commit ที่ระบุ โดยทิ้งการเปลี่ยนแปลงทั้งหมดใน working directory และ staging area ใช้อย่างระมัดระวัง เพราะจะลบการเปลี่ยนแปลงที่ยังไม่ได้ commit อย่างถาวร

สำคัญ: อย่าใช้ git reset --hard กับ commit ที่ได้ push ไปยังสาขาระยะไกลที่แชร์แล้ว เพราะเป็นการเขียนทับประวัติ และจะสร้างปัญหาร้ายแรงให้เพื่อนร่วมทีมที่ได้ pull commit เหล่านั้นไปแล้ว ให้ใช้ git revert แทนสำหรับ commit สาธารณะ

ความสำคัญของ git push --force-with-lease เมื่อเทียบกับ git push --force คืออะไร?

git push --force-with-lease เป็นแนวทางที่ระมัดระวังมากกว่าในการบังคับ push การเปลี่ยนแปลงไปยัง repository ระยะไกล เมื่อเทียบกับ git push --force เพราะช่วยป้องกันการเขียนทับการเปลี่ยนแปลงของผู้อื่นโดยไม่ตั้งใจ

เมื่อใช้ git push --force จะเป็นการบังคับ push การเปลี่ยนแปลงไปยังระยะไกลโดยไม่คำนึงว่ามีผู้อื่นอัปเดตตั้งแต่การ fetch ครั้งล่าสุดหรือไม่ ซึ่งอาจทำให้งานของนักพัฒนาคนอื่นสูญหายโดยไม่ตั้งใจ

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

git rebase คืออะไร และต่างจาก git merge อย่างไร?

ทั้ง git rebase และ git merge ใช้รวมการเปลี่ยนแปลงจากสาขาหนึ่งไปยังอีกสาขาหนึ่ง แต่ทำงานต่างกัน

  • git merge รวมประวัติของสองสาขาโดยสร้าง "merge commit" ใหม่ เก็บประวัติเต็มว่ามีการแยกและกลับมารวมกันเมื่อใด ซึ่งเป็นประโยชน์ต่อการตรวจสอบย้อนหลังและความโปร่งใสของทีม

  • git rebase ย้ายหรือเล่นซ้ำ commit จากสาขาหนึ่งไปไว้บนอีกสาขาหนึ่ง ทำให้ได้ประวัติเส้นตรงที่สะอาด ไม่มี merge commit ช่วยให้อ่าน log ง่ายขึ้น แต่เป็นการเขียนทับประวัติ commit ดังนั้นกฎทองของการ rebase คือ: อย่า rebase สาขาที่มีผู้อื่นใช้งานอยู่

ความแตกต่างระหว่าง git clone และ git fork คืออะไร?

Cloning คือการสร้างสำเนา repository ระยะไกลมายังเครื่องของคุณ โดยยังเชื่อมต่อกับ repository เดิมและสามารถ push กลับได้ (หากมีสิทธิ์)

git clone https://github.com/user/repo.git
Forking คือการสร้างสำเนา repository ของผู้อื่นบนฝั่งเซิร์ฟเวอร์ภายใต้บัญชีของคุณเอง — โดยทั่วไปบน GitHub หรือ GitLab คุณเป็นเจ้าของ fork และ push ได้อย่างอิสระ เมื่อพร้อมเปลี่ยนแปลงแล้ว ให้ส่ง pull request กลับไปยัง repository ต้นฉบับ

Forking เป็นเวิร์กโฟลว์มาตรฐานสำหรับการมีส่วนร่วมกับโครงการโอเพนซอร์สที่คุณไม่มีสิทธิ์เขียนโดยตรงใน repo ต้นฉบับ

การเตรียมตัวสำหรับการสัมภาษณ์เกี่ยวกับ Git

การนำเสนอความรู้และประสบการณ์ด้าน Git ระหว่างการสัมภาษณ์เป็นสิ่งสำคัญ เพื่อแสดงความเชี่ยวชาญในการควบคุมเวอร์ชันและการทำงานร่วมกันในทีมพัฒนาซอฟต์แวร์

มาดูเคล็ดลับที่ควรปฏิบัติเมื่อเตรียมตัวสำหรับการสัมภาษณ์ด้านเทคนิค เพื่อสื่อสารทักษะ Git ได้อย่างมีประสิทธิภาพ:

ทำความเข้าใจพื้นฐานของ Git

ตรวจสอบให้แน่ใจว่ามีความเข้าใจพื้นฐานของ Git อย่างมั่นคง รวมถึง repository, การสร้างสาขา, การผสาน, commit และคำสั่งพื้นฐานอย่าง pull, push, clone และ commit ความรู้พื้นฐานนี้จะเป็นฐานของการสนทนาในระหว่างการสัมภาษณ์ อีกทั้งควรเข้าใจหลักการสำคัญอย่างระบบควบคุมเวอร์ชัน และแยกความแตกต่างระหว่าง Git กับระบบควบคุมเวอร์ชันอื่นๆ

สุดท้าย ทำความคุ้นเคยกับวิธีการทำงานกับ Git หลากหลายแบบ เช่น Git Flow, GitHub Flow และ GitLab Flow ประเมินข้อดีข้อเสียของแต่ละแนวทาง และพิจารณาสถานการณ์ที่เหมาะสมในการใช้งาน

บทความ คู่มือ Git ฉบับสมบูรณ์ ของเราเป็นจุดเริ่มต้นที่ดีในการทำความคุ้นเคยกับพื้นฐาน

ฝึกปฏิบัติจริง

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

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

เรียนรู้ปัญหาที่พบบ่อยและวิธีแก้ไข

การใช้งาน Git ย่อมพบปัญหาเป็นเรื่องปกติ ปัญหาที่พบบ่อยได้แก่ merge conflict, สถานะ detached HEAD, การย้อนการเปลี่ยนแปลง และการกู้คืน commit ที่หายไป การวินิจฉัยปัญหาใน Git จะช่วยเพิ่มทักษะการแก้ปัญหา และทำให้เข้าใจกลไกภายในของ Git ลึกซึ้งยิ่งขึ้น

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

ฝึกสัมภาษณ์เสมือนจริง

การทำ mock interview ช่วยให้ผู้สมัครระบุจุดอ่อนในความรู้ Git และทักษะการสื่อสาร ทำให้โฟกัสการเตรียมตัวได้อย่างมีประสิทธิภาพ

นอกจากนี้ mock interview ยังเปิดโอกาสให้ผู้สมัครได้ฝึกแก้ปัญหาจากสถานการณ์จริงที่เกี่ยวกับ Git และแบบฝึกหัดการเขียนโค้ด การฝึกลงมือเช่นนี้ช่วยเสริมความมั่นใจในทักษะ Git และเพิ่มความสามารถในการสื่อสารความคิดอย่างชัดเจนระหว่างการสัมภาษณ์

สรุป

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

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

สำหรับการเรียนรู้เพิ่มเติม ลองดูแหล่งข้อมูลต่อไปนี้:

หัวข้อ

สานต่อการเรียนรู้ Git ของคุณวันนี้!

Tracks

วิศวกรข้อมูล ใน Python

40 ชม.
พัฒนาทักษะที่เป็นที่ต้องการเพื่อรับข้อมูล ทำความสะอาด จัดการข้อมูล และตั้งเวลาและติดตามไปป์ไลน์ได้อย่างมีประสิทธิภาพ ช่วยให้คุณโดดเด่นในสายงานวิศวกรรมข้อมูล
ดูรายละเอียดRight Arrow
เริ่มหลักสูตร
ดูเพิ่มเติมRight Arrow