git กับ GitHub ระบบเซฟและจัดการเวอร์ชันที่คนสร้างซอฟต์แวร์ทุกคนใช้
git คือทักษะพื้นฐานที่ขาดไม่ได้ของการ vibe code บทนี้อธิบายตั้งแต่ว่าทำไมมันถึงสำคัญ มันคืออะไรในเชิงทฤษฎี ส่วนประกอบและกฎของมัน ไปจนถึง GitHub และวิธีใช้งานจริงในแต่ละวัน
git กับ GitHub ระบบเซฟและจัดการเวอร์ชันที่คนสร้างซอฟต์แวร์ทุกคนใช้
เช้านี้เว็บที่คุณสร้างกับ AI ยังทำงานดีอยู่เลย พอช่วงบ่ายคุณบอก AI ให้แก้นั่นนิดนี่หน่อยสามสี่รอบ จู่ ๆ หน้าจอก็ขึ้นแดง ปุ่มที่เคยกดได้หายไป คุณนั่งมองมันแล้วท้องหล่นวูบ เพราะไม่รู้เลยว่าจะกลับไปหาเวอร์ชันเมื่อเช้าที่ยังดีอยู่ได้ยังไง
เครื่องมือที่แก้ปัญหานี้ และเป็นหนึ่งในทักษะที่สำคัญที่สุดของการ vibe code มีชื่อว่า git บทนี้จะพาคุณรู้จักมันตั้งแต่ต้น ทั้งว่าทำไมมันถึงสำคัญ มันคืออะไรในเชิงหลักการ ส่วนประกอบของมันมีอะไรบ้าง และพี่ใหญ่ของมันอย่าง GitHub ใช้งานจริงยังไงในแต่ละวัน
ทำไม git ถึงสำคัญเป็นพิเศษกับการ vibe code
ก่อนจะลงรายละเอียดว่ามันคืออะไร ขอปูให้ชัดก่อนว่าทำไมคนที่สร้างของกับ AI ถึงต้องรู้จักมันเป็นอันดับแรก ๆ
เวลาคุณ vibe code คุณสั่งให้ AI แก้โค้ดเร็วและบ่อยมาก วันหนึ่งอาจหลายสิบรอบ และคุณอ่านโค้ดที่มันเขียนไม่ออก แปลว่าคุณมองไม่เห็นว่าการแก้แต่ละครั้งปลอดภัยหรืออันตราย ผลคือสองอย่างนี้เกิดบ่อย คือของพังโดยไม่รู้ตัว และพอพังแล้วก็บอกไม่ได้ว่าการแก้ครั้งไหนเป็นต้นเหตุ
git แก้ปัญหานี้ตรงจุด เพราะมันทำให้ทุกขั้นของงานคุณมีจุดถอยที่กลับมาได้เสมอ พอมีจุดถอย การลองของใหม่ก็ไม่น่ากลัวอีกต่อไป AI แก้พังก็แค่ย้อนกลับ ไม่มีคำว่าทำพังแล้วกู้คืนไม่ได้
พูดให้ตรงกว่านั้น สำหรับคนที่เขียนโค้ดไม่เป็น git สำคัญยิ่งกว่าสำหรับโปรแกรมเมอร์อาชีพเสียอีก เพราะโปรแกรมเมอร์ที่แก้โค้ดเองได้ ถ้าของพังเขายังนั่งไล่แก้กลับมาเองได้ แต่คุณทำแบบนั้นไม่ได้ ความสามารถในการกดย้อนกลับไปจุดที่ยังดีอยู่ จึงเป็นตาข่ายนิรภัยหลักของคุณ ไม่ใช่ของเสริม
💡 ใจความสำคัญ: การ vibe code คือการบินโดยมองเห็นน้อยกว่าคนเขียนโค้ดเอง git คือสิ่งที่ทำให้คุณกล้าบินทั้งที่มองเห็นน้อย เพราะมันรับประกันว่าคุณถอยกลับได้เสมอ
git คืออะไร และทำไมถึงเป็นมาตรฐานของทั้งวงการ
พูดให้สั้นที่สุดแบบที่คุณจำกลับไปเล่าให้คนอื่นฟังได้ git คือโปรแกรมที่คอยจดประวัติไฟล์ทั้งหมดของโปรเจกต์ ให้คุณย้อนเวลากลับไปเวอร์ชันไหนก็ได้ที่เคยมี คำนี้อ่านว่า กิต
git ไม่ใช่เครื่องมือเฉพาะกลุ่มหรือของแปลกใหม่ มันคือระบบจัดการเวอร์ชัน (version control) ที่ได้รับความนิยมที่สุดในโลก ถูกสร้างขึ้นตั้งแต่ปี 2005 และกลายเป็นมาตรฐานที่ทีมซอฟต์แวร์แทบทุกที่ทั่วโลกใช้ เครื่องมือ AI ที่ใช้สร้างของอย่าง Claude Code หรือ Cursor ก็ตั้งอยู่บนสมมติฐานว่าคุณใช้ git ทั้งนั้น
แปลว่าการลงทุนทำความเข้าใจ git หนึ่งครั้ง คือการเรียนรู้ภาษากลางของการเซฟและจัดการเวอร์ชันซอฟต์แวร์ที่ใช้ได้ตลอดไป ไม่ว่าคุณจะย้ายไปใช้เครื่องมือไหนต่อ
ทฤษฎีของ git ส่วนประกอบ การทำงาน และกฎ
ส่วนนี้คือหัวใจเชิงหลักการของบท ขอให้อ่านช้า ๆ เพราะเมื่อเข้าใจส่วนประกอบและกฎไม่กี่ข้อนี้แล้ว ทุกอย่างที่เหลือจะง่ายขึ้นทันที git ประกอบด้วยแนวคิดหลักไม่กี่ตัว แต่ละตัวมีนิยาม มีวิธีทำงาน และมีกฎของมัน
repository หรือเรียกสั้น ๆ ว่า repo นิยาม คือโฟลเดอร์โปรเจกต์ของคุณที่อยู่ใต้การดูแลของ git มันเก็บทั้งไฟล์เวอร์ชันปัจจุบันและประวัติทั้งหมดของไฟล์เหล่านั้นไว้ด้วยกัน ทำงานยังไง พอคุณสั่งให้ git เริ่มดูแลโฟลเดอร์หนึ่ง มันจะสร้างที่เก็บประวัติซ่อนไว้ในโฟลเดอร์นั้น ตั้งแต่นั้นทุกการเปลี่ยนแปลงที่คุณบันทึกจะถูกจดลงประวัติของ repo กฎ หนึ่งโปรเจกต์เท่ากับหนึ่ง repo
commit อ่านว่า คอมมิต นิยาม คือภาพถ่ายของไฟล์ทุกไฟล์ ณ ขณะหนึ่ง พร้อมข้อความสั้น ๆ กำกับว่าตอนนั้นทำอะไรไป ทำงานยังไง เมื่อ commit git จะถ่ายรูปสถานะปัจจุบันของไฟล์ทั้งหมด แช่แข็งไว้ ติดรหัสและข้อความ แล้วเก็บต่อท้ายเข้าไปในประวัติ กฎ commit ที่เก็บแล้วจะไม่ถูกแก้และไม่ถูกทับ ประวัติมีแต่ยาวขึ้น ภาพเก่าทุกภาพยังอยู่ครบ นี่คือเหตุผลที่การ commit ปลอดภัยเสมอ มันไม่เคยทำให้คุณเสียอะไร มีแต่เพิ่มจุดให้กลับมา
ตรงนี้ขอแทรกความเข้าใจผิดที่พบบ่อย หลายคนคิดว่าถ้าพังก็แค่กด Cmd-Z undo เอา จริง ๆ แล้ว undo กับ commit เป็นคนละชั้นกัน undo คือความจำชั่วคราวของโปรแกรมที่เปิดอยู่ ปิดโปรแกรมหรือรีสตาร์ตเครื่องก็หาย และถอยได้ทีละขั้นตามลำดับเท่านั้น ส่วน commit คือภาพถ่ายที่เก็บลงคลังถาวร ผ่านไปสามเดือนก็ยังกระโดดกลับไปได้ตรงจุด
branch อ่านว่า แบรนช์ นิยาม คือเส้นทางการทำงานคู่ขนานที่แยกออกจากเส้นหลัก ให้คุณลองของใหม่โดยไม่กระทบงานหลัก หน้าตาเป็นยังไง ให้นึกถึงกิ่งไม้ที่แตกออกจากลำต้น ลำต้นคือเส้นหลักที่มักมีชื่อว่า main ส่วนกิ่งคือที่ที่คุณไปทดลอง ทำงานยังไง ในทางเทคนิค branch คือตัวชี้ที่ชี้ไปยัง commit หนึ่ง เมื่อคุณ commit เพิ่มบนกิ่งนั้น ตัวชี้ของกิ่งก็ขยับตามไป ส่วนเส้น main อยู่กับที่ไม่ถูกแตะ ถ้าผลทดลองดีก็รวมกลับเข้า main ถ้าไม่ดีก็ทิ้งทั้งกิ่ง เส้นหลักยังสะอาดเหมือนเดิม กฎ เส้นหลัก main ควรอยู่ในสภาพใช้งานได้เสมอ ของที่ยังไม่แน่ใจให้ไปทดลองบน branch แยก
merge อ่านว่า เมิร์จ นิยาม คือการรวมงานจาก branch หนึ่งกลับเข้าอีก branch หนึ่ง ทำงานยังไง git เอาการเปลี่ยนแปลงจากกิ่งทดลองมารวมเข้ากับเส้นหลัก ถ้าทั้งสองฝั่งบังเอิญแก้ไฟล์จุดเดียวกัน จะเกิดสิ่งที่เรียกว่า conflict ซึ่งต้องเลือกว่าจะเอาฝั่งไหน ในการ vibe code คุณให้ AI ช่วยจัดการ conflict ได้ กฎ รวมกิ่งเข้า main เมื่อของบนกิ่งทำงานได้ดีแล้วเท่านั้น
worktree อ่านว่า เวิร์กทรี เป็นของขั้นสูง รู้ไว้ก่อน ยังไม่ต้องใช้ก็ได้ นิยาม ปกติ repo หนึ่งคุณเปิดทำงานได้ทีละ branch ในโฟลเดอร์เดียว worktree คือความสามารถที่ให้คุณกางหลาย branch ออกมาเป็นหลายโฟลเดอร์พร้อมกัน ใช้ตอนไหนในการ vibe code เช่นอยากให้ AI ลองแก้แบบเสี่ยงบน branch ใหม่ในอีกโฟลเดอร์หนึ่ง ขณะที่โฟลเดอร์เดิมที่ยังดีอยู่เปิดค้างไว้ให้เทียบได้ตลอดเวลา โดยไม่ต้องสลับไปมา กฎ เป็นฟีเจอร์ขั้นสูง ไม่จำเป็นต้องใช้ตั้งแต่วันแรก แต่ควรรู้ว่ามีไว้ เผื่อวันที่ต้องลองหลายทางพร้อมกัน
ถ้าจะสรุปกฎทั้งหมดให้เป็นหลักการที่ถือไว้ใช้ได้ทุกวัน มีอยู่สี่ข้อ
- ประวัติมีแต่เพิ่ม ไม่เคยหาย ทุกอย่างจึงย้อนกลับได้
- เส้นหลัก main ต้องใช้งานได้เสมอ ของเสี่ยงไปอยู่บน branch
- commit บ่อย ๆ ในจังหวะที่ของยังดี เท่ากับมีจุดถอยถี่ ยิ่งปลอดภัย
- ส่งงานขึ้นที่เก็บออนไลน์สม่ำเสมอ เท่ากับงานถูกสำรองไว้ ไม่หายแม้เครื่องพัง
ข้อสุดท้ายพาเราไปสู่ GitHub
GitHub บ้านออนไลน์ของโปรเจกต์คุณ และวิธีใช้ประจำวัน
ที่ผ่านมา git ทำงานอยู่บนเครื่องคุณเครื่องเดียว ประวัติทั้งหมดเก็บอยู่ในโฟลเดอร์บนเครื่องคุณ ซึ่งแปลว่าถ้าเครื่องหาย เครื่องพัง หรือไฟล์เสีย ประวัติก็หายไปด้วย นี่คือช่องว่างที่ GitHub มาอุด
GitHub คืออะไร git คือเครื่องจดประวัติที่อยู่บนเครื่องคุณ GitHub คือเว็บไซต์ที่เก็บสำเนาของ repo คุณไว้บนออนไลน์ พูดง่าย ๆ git คือเครื่องมือ GitHub คือบ้านออนไลน์ของประวัติที่เครื่องมือนั้นจดไว้ สองอย่างนี้คนละตัวกัน ใช้คู่กัน
ทำไมต้องมี GitHub มีเหตุผลหลักสามข้อ
- สำรองงาน ถ้าเครื่องคุณพังหรือหาย งานและประวัติทั้งหมดยังอยู่ครบบน GitHub
- เป็นต้นทางของการขึ้นเว็บจริง ระบบที่เอาเว็บคุณไปเผยแพร่ มักดึงโค้ดไปจาก GitHub (เรื่องนี้จะพูดเต็ม ๆ ในบท deploy)
- เป็นที่กลาง ให้เครื่องมือ คนร่วมงาน หรือตัวคุณเองจากอีกเครื่อง เข้าถึงโปรเจกต์เดียวกันได้
คำที่ต้องรู้สองคำ
- push อ่านว่า พุช คือการส่ง commit จากเครื่องคุณขึ้นไปเก็บบน GitHub พูดง่าย ๆ คือ sync ขึ้น
- pull อ่านว่า พูล คือการดึงของล่าสุดจาก GitHub ลงมาที่เครื่องคุณ คือ sync ลง
วิธีใช้ในแต่ละวัน ทำตามนี้
- สมัครบัญชี GitHub ฟรีที่ github.com ทำครั้งเดียวจบ
- สร้าง repository สำหรับโปรเจกต์ หรือบอกให้ AI สร้างและเชื่อมโปรเจกต์ในเครื่องเข้ากับ GitHub ให้ ทำครั้งเดียวต่อหนึ่งโปรเจกต์
- ทำงานตามปกติ สั่ง AI แก้ของ แล้วให้มัน commit เก็บเป็นช่วง ๆ ระหว่างทาง
- พอถึงจุดที่งานคืบหน้าน่าพอใจ สั่งว่า push ขึ้น GitHub ที เพื่อสำรองงานขึ้นออนไลน์ ทำให้ติดเป็นนิสัยเหมือนเซฟไฟล์ขึ้นคลาวด์
- เปิดหน้า repo ของคุณบน GitHub ดูได้ว่ามีประวัติอะไรขึ้นไปบ้าง ของล่าสุดครบไหม
จังหวะที่ดีคือ commit ให้ถี่ระหว่างทาง และ push เมื่อจบก้อนงานหนึ่ง อย่างน้อยวันละครั้งถ้าทำงานต่อเนื่อง ส่วนใครทำอะไร AI เป็นคนพิมพ์คำสั่ง push และ pull ให้ ส่วนคุณเป็นคนตัดสินใจว่าเมื่อไรควร push และคอยเปิด GitHub เช็คว่างานขึ้นไปครบ
เห็นภาพรวม ทั้งหมดนี้ทำงานต่อกันยังไงในงานจริง
จนถึงตรงนี้คุณรู้จักส่วนประกอบทีละตัวแล้ว แต่ของพวกนี้จะเข้าใจง่ายที่สุดเมื่อเห็นมันร้อยต่อกันเป็นลำดับในงานจริง สมมติคุณกำลังจะให้ AI เพิ่มปุ่มบันทึกลงในแอป นี่คือสิ่งที่เกิดขึ้นทีละขั้น และสังเกตว่าทุกคำที่เพิ่งเรียนมาโผล่มาทำงานตรงไหน
- เริ่มจากของที่ใช้งานได้ ตอนนี้โปรเจกต์ของคุณคือ repo หนึ่ง และเส้นหลัก main อยู่ในสภาพดี ใช้งานได้
- ก่อนแตะอะไร เซฟไว้ก่อน คุณสั่งว่า commit ของที่ดีไว้ก่อน AI ถ่ายรูปสถานะปัจจุบันเก็บเป็น commit หนึ่ง ใส่ข้อความกำกับเช่น หน้าหลักทำงานปกติ ตอนนี้คุณมีจุดถอยแล้ว
- แตกกิ่งไปลองของเสี่ยง งานนี้เสี่ยงเพราะปุ่มใหม่อาจกระทบของเดิม คุณเลยสั่งว่า สร้าง branch ใหม่ไว้ทดลอง AI แตกกิ่งใหม่ชื่อ add-save-button ออกมาจาก main ตอนนี้คุณทำงานอยู่บนกิ่ง ส่วน main ไม่ถูกแตะเลย
- ทำงานบนกิ่ง เก็บเป็นช่วง บนกิ่งนั้นคุณสั่ง AI ให้เพิ่มปุ่ม AI แก้ไฟล์ในโปรเจกต์ พอคืบหน้าก็ commit เก็บไว้เป็นช่วง ๆ บนกิ่ง
- ถึงจุดตัดสิน คุณลองเปิดดูในเครื่อง
- ถ้าปุ่มทำงานดี ไปข้อต่อไป
- ถ้าพัง คุณสั่งว่า กลับไป commit ก่อนหน้า ซึ่งคือ revert หรือถ้าเละมากก็ทิ้งทั้งกิ่งนี้ไปเลย แล้วกลับไปที่ main ที่ยังสะอาดเหมือนไม่เคยมีอะไรเกิดขึ้น ลองใหม่ได้สบาย
- รวมกลับเข้าเส้นหลัก พอใจแล้วคุณสั่งว่า merge กิ่ง add-save-button กลับเข้า main ตอนนี้ปุ่มใหม่มาอยู่บนเส้นหลักแล้ว และ main ก็ยังใช้งานได้
- สำรองขึ้นออนไลน์ ปิดท้ายคุณสั่งว่า push ขึ้น GitHub งานล่าสุดทั้งหมดถูกสำรองขึ้นออนไลน์ และพร้อมให้ระบบเอาไปขึ้นเว็บจริงต่อ
สังเกตว่า commit branch merge revert push ไม่ได้อยู่แยกกัน แต่ร้อยกันเป็นวงจรเดียว คือ เซฟของดีไว้ก่อน แตกกิ่งไปลอง ลองแล้วเก็บเป็นช่วง เวิร์กก็รวมกลับ ไม่เวิร์กก็ถอยหรือทิ้งกิ่ง แล้วสำรองขึ้นออนไลน์ วงจรนี้คือจังหวะการทำงานจริงที่คุณจะวนทำซ้ำไปเรื่อย ๆ ทุกครั้งที่สร้างของ
และถ้าวันไหนอยากเทียบของเก่ากับของใหม่พร้อมกันโดยไม่ต้องสลับกิ่งไปมา นั่นแหละคือจังหวะที่ worktree ที่พูดถึงไปก่อนหน้ามีประโยชน์ คือกาง main กับกิ่งทดลองออกมาเป็นสองโฟลเดอร์เปิดคู่กัน
แล้วในทางปฏิบัติ คุณต้องทำอะไรบ้าง
ข่าวดีคือคุณไม่ต้องพิมพ์คำสั่ง git หรือ GitHub เองสักตัว AI เป็นคนพิมพ์ให้ ไม่ว่าจะผ่าน Claude Code บนเครื่อง Mac หรือผ่านโปรแกรมแก้โค้ดอย่าง VS Code หลักการเดียวกัน หน้าที่ของคุณคือรู้ความหมายของคำพวกนี้ เพื่อสั่งให้ถูกจังหวะและอ่านออกว่า AI รายงานกลับมาว่าอะไร
ประโยคที่คุณจะได้ใช้บ่อยมีไม่กี่ประโยค
- ก่อนแก้ของเสี่ยง commit ของที่ดีอยู่ตอนนี้เก็บไว้ก่อน แล้วค่อยแก้
- จะลองของที่กลับยาก สร้าง branch ใหม่ไว้ทดลองก่อน
- พอมันพัง มันพังแล้ว กลับไปที่ commit ก่อนหน้านี้ที
- จบก้อนงาน push ขึ้น GitHub ที
ตัวอย่างจริงจากเว็บ AI ภาษาคน เว็บนี้เอง ก่อนที่เจ้าของจะไปแก้ข้อมูลอีเมลที่ฝังอยู่ในประวัติทั้งหมด ซึ่งเป็นงานที่ย้อนกลับยากมาก เขาสั่งให้สร้าง branch สำรองเก็บไว้ก่อนหนึ่งเส้น ตั้งชื่อว่า backup/pre-email-rewrite เผื่อมีอะไรพลาดจะได้ดึงทุกอย่างกลับมาได้ทันที นี่คือการเอา branch มาใช้เป็นจุดเซฟในงานจริง
ภาพช่วยจำ
ตอนนี้คุณเข้าใจกลไกจริงแล้ว ขอเติมภาพหนึ่งไว้ช่วยจำ git เหมือนการเซฟเกมก่อนไปสู้บอส ทุกครั้งที่เซฟ คุณได้จุดที่กลับมาโหลดใหม่ได้ ตายไปก็ไม่เสียอะไร เลยกล้าลองท่าเสี่ยง
จุดที่การเปรียบเทียบนี้ใช้ไม่ได้ และเป็นจุดที่ git เก่งกว่าเกม คือเซฟเกมส่วนใหญ่เป็นช่องเดียวเส้นตรง เซฟทับไปเรื่อย ๆ ของเก่าหาย แต่ git เก็บทุกเซฟไว้ตลอดไป และยังแตกเป็นสายคู่ขนานอย่าง branch ให้ลองหลายทางพร้อมกันได้ ส่วน GitHub ก็เหมือนการอัปเซฟทั้งหมดขึ้นเก็บบนคลาวด์ เครื่องพังเซฟก็ไม่หาย
ถึงตรงนี้ ต่อให้ลืมภาพเซฟเกมไป คุณก็ยังอธิบายได้ว่า git คือเครื่องถ่ายรูปไฟล์เก็บเป็นประวัติที่ย้อนกลับได้ และ GitHub คือที่เก็บประวัตินั้นบนออนไลน์ ภาพเซฟเกมเป็นแค่หมุดช่วยจำ ไม่ใช่ตัวคำอธิบาย
ส่วนเรื่องวินัยว่าควร commit ตอนไหน บ่อยแค่ไหน และหลักการไม่มีจุดถอยก็ไม่แตะ ที่ทำให้คุณกล้าสร้างของอย่างมั่นใจ เราจะลงลึกในภาคต่อไป ตอนนี้ขอแค่ให้คุณมีเครื่องย้อนเวลานี้อยู่ในมือ และเข้าใจว่ามันทำงานยังไง เพราะมันคือก้าวแรกที่เปลี่ยนคุณจากคนที่สั่ง AI แบบลุ้น ๆ ไปเป็นคนที่คุมงานได้จริง