Git เท่าที่ต้องรู้

ลองนึกภาพว่าคุณเปิด AI coding agent แล้วพิมพ์ว่า

ถ้าใช้ AI ทำเว็บมาสักพัก ประโยคนี้อาจฟังดูธรรมดา งานเล็กนิดเดียว และ AI ก็น่าจะทำให้จบได้

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

เราไม่จำเป็นต้องจำคำสั่ง Git ทั้งหมดเพื่อดูแลเรื่องเหล่านี้ แต่ควรรู้ว่าแต่ละช่วงของงานกำลังเกิดขึ้นที่ไหน

บทความนี้จึงไม่ใช่คู่มือท่อง command แต่เป็นแผนที่สำหรับคนที่ใช้ AI เขียนโค้ดและอยากรู้ว่า code อยู่ที่ไหน เปลี่ยนอะไร และเวอร์ชันไหนกำลังอยู่บนเว็บ

เริ่มจากแยก Git, repo และ GitHub ให้ออกจากกัน

สามคำนี้มักถูกใช้ปนกัน แต่ทำหน้าที่คนละอย่าง

พูดสั้นๆ คือ repo คือของ, Git คือระบบ, GitHub คือสถานที่หนึ่งที่เอาระบบนี้ไปใช้

ใน repo เดียวกันยังมีอีกสองตำแหน่งที่ควรแยกให้ออก:

• Local คือ repo บนเครื่องที่ AI กำลังแก้ไฟล์
• Remote คือ repo อีกสำเนาที่อยู่บน GitHub หรือบริการอื่น

ดังนั้น AI บอกว่า “แก้เสร็จแล้ว” ยังไม่ได้แปลว่างานอยู่บน GitHub และบอกว่า “push แล้ว” ก็ยังไม่ได้แปลว่าเว็บ production เปลี่ยนแล้ว

เมื่อใช้คนเดียว: ดูสถานะก่อน แล้วค่อยให้ AI แก้

ปัญหาพื้นฐานที่เจอบ่อยไม่ใช่ Git พัง แต่เป็นการเริ่มงานใหม่ทั้งที่มีงานเก่าค้างอยู่ หรือให้ AI แก้หลายเรื่องจนรวมกันอยู่ในก้อนเดียว

ก่อนเริ่ม ลองสั่ง AI ว่า:

คำตอบนี้ควรทำให้เราเห็นอย่างน้อยสามเรื่อง:

1. ตอนนี้อยู่ branch ไหน
2. มีไฟล์จากงานเก่าค้างอยู่หรือไม่
3. repo นี้เชื่อม remote ที่ไหน

ก่อน AI เริ่มแก้ ให้ดูชื่อ branch ที่มันแสดง ถ้าเห็นชื่ออย่าง feature/download-cheat-sheet แปลว่างานนี้ถูกแยกออกจาก main แล้ว แต่ถ้ายังเห็น main ค่อยบอก AI ว่า “แยก branch สำหรับงานนี้ก่อน”

Branch ไม่ใช่การ copy โฟลเดอร์ใหม่ให้เราเห็น แต่เป็นพื้นที่ประวัติที่แยกงานเรื่องนี้ออกจาก main ถ้า AI แก้ผิดทิศ งานหลักจึงยังไม่เปลี่ยนตามไปทันที

Branch เปิดพื้นที่ให้งานหนึ่งเรื่องเดินแยกออกมา โดย main และประวัติเดิมยังอยู่ที่เดิม

ถ้าเผลอให้ AI แก้บน main ไปแล้ว

เรื่องนี้เกิดบ่อยและแก้ได้ ตราบใดที่ยังไม่ commit งานที่แก้ไว้ก็ยังไม่ผูกกับ branch ใด เราจึงย้ายไปไว้บน branch ใหม่ได้โดยไม่ต้องทำงานซ้ำ

หลังย้ายเสร็จให้ดูสองเรื่อง: งานไปอยู่บน branch ใหม่ครบ และ main กลับไปเหมือนก่อนเริ่มแก้

หลังแก้เสร็จ: อ่าน diff ก่อนรับงาน

หลัง AI แก้ มันมักแสดงข้อความอย่าง Edited 4 files, ตัวเลข +186 -49 และปุ่ม Review ให้อยู่แล้ว สิ่งนี้คือ diff หรือความต่างระหว่างก่อนแก้กับหลังแก้

เราไม่ต้องอ่านโค้ดได้ทุกบรรทัด แค่เริ่มจากสามคำถาม: แตะกี่ไฟล์ ชื่อไฟล์เกี่ยวกับงานนี้ไหม และผู้ใช้จะเห็นอะไรเปลี่ยน เครื่องหมาย + คือสิ่งที่เพิ่ม ส่วน - คือสิ่งที่ลบหรือแทนที่ ถ้ายังอ่านไม่ออก ค่อยให้ AI ช่วยแปล:

Diff บอกว่าอะไรเปลี่ยน ส่วน test บอกว่าสิ่งที่เปลี่ยนนั้นใช้งานได้หรือไม่ เราต้องการทั้งสองอย่างก่อนรับงาน

ก่อนบันทึก: Commit ต้องเล่าได้ว่างานนี้ทำอะไร

Commit คือ checkpoint พร้อมป้ายชื่อ วันหลังเราจะใช้ป้ายนี้ย้อนดูว่าเกิดอะไรขึ้น ถ้า AI เสนอข้อความกว้าง ๆ อย่าง Update files หรือ Fix changes ประวัติจะมีอยู่แต่ช่วยให้เราเข้าใจอะไรไม่ได้

ข้อความที่ดีกว่าควรบอกผลลัพธ์ของงานหนึ่งเรื่อง เช่น Add Git cheat sheet download ก่อนอนุมัติให้ดูว่า ไฟล์เป็นของงานนี้ทั้งหมด ผลทดสอบผ่าน และ message เล่าใจความสำคัญได้

AI ช่วยเสนอ commit message ได้ แต่เราเป็นคนตรวจว่ามันเล่าเรื่องสำคัญของงานถูกหรือไม่

Commit คือ checkpoint หนึ่งจุดในประวัติ ไม่ใช่การส่งงานขึ้น GitHub หรือขึ้นเว็บ

ถ้าอยากย้อนกลับ หรือล้างงานทิ้ง

เมื่อ commit คือ checkpoint คำถามเรื่องย้อนกลับก็ตอบง่ายขึ้น: ย้อนได้ไกลเท่าที่เคยตั้ง checkpoint ไว้

เวลาย้อน เราไม่ต้องจำรหัสของ commit ก็ได้ อ้างด้วยใจความของงานได้เลย

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

เมื่อจะขึ้นเว็บ: commit, push และ deploy เป็นคนละเหตุการณ์

ตอนนี้งานใหม่อยู่ใน commit บน feature/download-cheat-sheet แต่ถ้า GitHub Pages ของโปรเจกต์ publish จาก main เว็บจริงจะยังไม่เห็นงานนั้น

ก่อน merge ให้ AI ตรวจ configuration ของโปรเจกต์ก่อนว่า deployment อ่านจาก branch ใด แล้วขอดู commit ที่กำลังจะเข้า main

เมื่อ merge แล้ว ประวัติของงานจึงกลับมาอยู่บน local main แต่ remote ยังไม่เปลี่ยนจนกว่าเราจะ push

Merge นำประวัติของ branch ที่ตรวจแล้วกลับเข้ามารวมกับ main; หลังจุดรวม งานเดินต่อบนเส้นหลักเดียวกัน

เส้นทางเต็มของงานนี้คือ:

feature commit → merge main → push main → deployment → เปิด public URL

หลัง push ควรดูหน้า deployment และเปิด URL จริงเพื่อลอง flow ที่ผู้ใช้จะทำ ไม่ใช่หยุดที่ข้อความว่า deploy สำเร็จ

จำไว้ว่า push ไม่ได้แปลว่า deploy เสมอไป บางโปรเจกต์ deploy จาก main บางโปรเจกต์ใช้ branch หรือขั้นตอนอื่น ต้องดู configuration ของโปรเจกต์นั้น

เมื่อใช้กับคนอื่น: ไม่ push เข้า main ตรง แต่ส่งผ่าน Pull Request

สมมติว่างานดาวน์โหลดขึ้นเว็บแล้ว งานต่อไปคือเพิ่มวิดีโอ YouTube ตอนนี้ลงในหน้า นี่เป็นงานคนละชิ้น จึงควรเปิด branch ใหม่ชื่อ feature/add-youtube-video

เวลาทำงานร่วมกัน ปกติเราจะไม่ push เข้า main ตรง แม้ repository ยังอนุญาต เพราะ main เป็นเส้นหลักที่คนอื่นและระบบ deploy ใช้อ้างอิง

เริ่มจากรับข้อมูลล่าสุดจาก remote แล้วสร้าง branch จาก main ล่าสุด:

เมื่อเพิ่ม YouTube embed ตรวจ diff ทดลอง responsive และ commit แล้ว เรา push branch งาน ขึ้น GitHub จากนั้นเปิด Pull Request หรือ PR เข้า main

remote main ล่าสุด → branch งาน → commit → push branch → PR → review → merge

Pull Request ไม่ใช่เพียงปุ่มขอ merge แต่เป็นพื้นที่ให้ทุกคนเห็นว่าเปลี่ยนอะไร ทดสอบอย่างไร checks ผ่านหรือไม่ และยังมีอะไรควรตรวจก่อนแตะเส้นหลัก

ถ้าหลาย branch แก้ตำแหน่งเดียวกัน Git อาจหยุดด้วย merge conflict มันไม่ได้แปลว่า repo พัง เพียงแต่ Git ไม่รู้ว่าคำตอบสุดท้ายควรเป็นแบบไหน

อย่าสั่งเพียง “แก้ conflict ให้หน่อย” ลองใช้ว่า:

Written by

Palm

Writing about lifestyle, tech, and business.