# Git เท่าที่ต้องรู้ Category: tech · Language: th · Published: 2026-08-21 ลองนึกภาพว่าคุณเปิด AI coding agent แล้วพิมพ์ว่า แก้หน้า HTML นี้ โดยเพิ่มส่วนให้ดาวน์โหลด cheat sheet ไว้ตอนสุดท้าย แล้ว push เข้า main เพื่อไป production server เลย ถ้าใช้ AI ทำเว็บมาสักพัก ประโยคนี้อาจฟังดูธรรมดา งานเล็กนิดเดียว และ AI ก็น่าจะทำให้จบได้ แต่ในประโยคเดียวมีหลายเรื่องซ้อนกันอยู่: AI กำลังแก้ไฟล์บนเครื่องไหน งานเดิมมีอะไรค้างอยู่หรือไม่ สิ่งที่เปลี่ยนตรงกับที่ขอไหม งานถูกบันทึกหรือยัง กำลังส่ง branch ไหนขึ้น GitHub และ `main` เชื่อมกับเว็บจริงหรือเปล่า เราไม่จำเป็นต้องจำคำสั่ง Git ทั้งหมดเพื่อดูแลเรื่องเหล่านี้ แต่ควรรู้ว่าแต่ละช่วงของงานกำลังเกิดขึ้นที่ไหน บทความนี้จึงไม่ใช่คู่มือท่อง command แต่เป็นแผนที่สำหรับคนที่ใช้ AI เขียนโค้ดและอยากรู้ว่า **code อยู่ที่ไหน เปลี่ยนอะไร และเวอร์ชันไหนกำลังอยู่บนเว็บ** ## เริ่มจากแยก Git, repo และ GitHub ให้ออกจากกัน สามคำนี้มักถูกใช้ปนกัน แต่ทำหน้าที่คนละอย่าง | คำ | ความหมายแบบใช้งานจริง | |---|---| | **Repository หรือ repo** | โปรเจกต์พร้อมประวัติการเปลี่ยนแปลง | | **Git** | ระบบที่ติดตามและจัดการประวัตินั้น | | **GitHub** | บริการที่ใช้เก็บ repo กลาง ดูประวัติ เปิด PR และทำงานร่วมกัน | พูดสั้นๆ คือ **repo คือของ, Git คือระบบ, GitHub คือสถานที่หนึ่งที่เอาระบบนี้ไปใช้** ใน repo เดียวกันยังมีอีกสองตำแหน่งที่ควรแยกให้ออก: - **Local** คือ repo บนเครื่องที่ AI กำลังแก้ไฟล์ - **Remote** คือ repo อีกสำเนาที่อยู่บน GitHub หรือบริการอื่น ดังนั้น AI บอกว่า “แก้เสร็จแล้ว” ยังไม่ได้แปลว่างานอยู่บน GitHub และบอกว่า “push แล้ว” ก็ยังไม่ได้แปลว่าเว็บ production เปลี่ยนแล้ว

เราเรียนรู้อะไร Git, repo และ GitHub ไม่ใช่สิ่งเดียวกัน และงานอาจอยู่บน local หรือ remote

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

 ## เมื่อใช้คนเดียว: ดูสถานะก่อน แล้วค่อยให้ AI แก้ ปัญหาพื้นฐานที่เจอบ่อยไม่ใช่ Git พัง แต่เป็นการเริ่มงานใหม่ทั้งที่มีงานเก่าค้างอยู่ หรือให้ AI แก้หลายเรื่องจนรวมกันอยู่ในก้อนเดียว ก่อนเริ่ม ลองสั่ง AI ว่า: ตรวจว่าโฟลเดอร์นี้เป็น Git repo หรือยัง สรุป current branch, changed files, งานที่ยังไม่ได้ commit และ remote โดยยังไม่แก้ไฟล์หรือเปลี่ยนสถานะอะไร เช็กสถานะ repo นี้ให้หน่อย ยังไม่ต้องแก้อะไร คำตอบนี้ควรทำให้เราเห็นอย่างน้อยสามเรื่อง: 1. ตอนนี้อยู่ branch ไหน 2. มีไฟล์จากงานเก่าค้างอยู่หรือไม่ 3. repo นี้เชื่อม remote ที่ไหน ก่อน AI เริ่มแก้ ให้ดูชื่อ branch ที่มันแสดง ถ้าเห็นชื่ออย่าง `feature/download-cheat-sheet` แปลว่างานนี้ถูกแยกออกจาก `main` แล้ว แต่ถ้ายังเห็น `main` ค่อยบอก AI ว่า “แยก branch สำหรับงานนี้ก่อน” Branch ไม่ใช่การ copy โฟลเดอร์ใหม่ให้เราเห็น แต่เป็นพื้นที่ประวัติที่แยกงานเรื่องนี้ออกจาก `main` ถ้า AI แก้ผิดทิศ งานหลักจึงยังไม่เปลี่ยนตามไปทันที ![เส้นประวัติ main สีเข้มเดินตรงไป ขณะที่เส้นงานสีส้มแยกออกไปเป็น branch ใหม่](https://assets.onproud.com/posts/2026/08/know-just-enough-git/branch-v1.jpg) *Branch เปิดพื้นที่ให้งานหนึ่งเรื่องเดินแยกออกมา โดย `main` และประวัติเดิมยังอยู่ที่เดิม* ### ถ้าเผลอให้ AI แก้บน `main` ไปแล้ว เรื่องนี้เกิดบ่อยและแก้ได้ ตราบใดที่ยังไม่ commit งานที่แก้ไว้ก็ยังไม่ผูกกับ branch ใด เราจึงย้ายไปไว้บน branch ใหม่ได้โดยไม่ต้องทำงานซ้ำ ผมแก้อยู่บน main ช่วยย้ายงานที่ยังไม่ commit ไป branch ใหม่ให้หน่อย หลังย้ายเสร็จให้ดูสองเรื่อง: งานไปอยู่บน branch ใหม่ครบ และ `main` กลับไปเหมือนก่อนเริ่มแก้ ### หลังแก้เสร็จ: อ่าน diff ก่อนรับงาน หลัง AI แก้ มันมักแสดงข้อความอย่าง `Edited 4 files`, ตัวเลข `+186 -49` และปุ่ม `Review` ให้อยู่แล้ว สิ่งนี้คือ **diff** หรือความต่างระหว่างก่อนแก้กับหลังแก้ เราไม่ต้องอ่านโค้ดได้ทุกบรรทัด แค่เริ่มจากสามคำถาม: **แตะกี่ไฟล์ ชื่อไฟล์เกี่ยวกับงานนี้ไหม และผู้ใช้จะเห็นอะไรเปลี่ยน** เครื่องหมาย `+` คือสิ่งที่เพิ่ม ส่วน `-` คือสิ่งที่ลบหรือแทนที่ ถ้ายังอ่านไม่ออก ค่อยให้ AI ช่วยแปล: สรุป diff นี้เป็นภาษาคนทั่วไปให้หน่อย ผู้ใช้จะเห็นอะไรเปลี่ยน แตะไฟล์ไหน และมีอะไรเกินจากงานที่ขอไหม Diff บอกว่าอะไรเปลี่ยน ส่วน test บอกว่าสิ่งที่เปลี่ยนนั้นใช้งานได้หรือไม่ เราต้องการทั้งสองอย่างก่อนรับงาน ### ก่อนบันทึก: Commit ต้องเล่าได้ว่างานนี้ทำอะไร Commit คือ checkpoint พร้อมป้ายชื่อ วันหลังเราจะใช้ป้ายนี้ย้อนดูว่าเกิดอะไรขึ้น ถ้า AI เสนอข้อความกว้าง ๆ อย่าง `Update files` หรือ `Fix changes` ประวัติจะมีอยู่แต่ช่วยให้เราเข้าใจอะไรไม่ได้ ข้อความที่ดีกว่าควรบอกผลลัพธ์ของงานหนึ่งเรื่อง เช่น `Add Git cheat sheet download` ก่อนอนุมัติให้ดูว่า **ไฟล์เป็นของงานนี้ทั้งหมด ผลทดสอบผ่าน และ message เล่าใจความสำคัญได้** แสดงผลทดสอบ ไฟล์ที่จะเข้า commit และ commit message ที่เสนอ พร้อมอธิบายสั้น ๆ ว่าข้อความนี้บอกผลลัพธ์ของงานอย่างไร รอฉันอนุมัติก่อน commit เตรียม commit งานนี้พร้อม message ให้ผมรีวิวก่อน AI ช่วยเสนอ commit message ได้ แต่เราเป็นคนตรวจว่ามันเล่าเรื่องสำคัญของงานถูกหรือไม่ ![การ์ดห้าใบเรียงเป็นลำดับ โดยการ์ดใบสุดท้ายมีจุดสีส้มแสดง checkpoint ที่เลือกบันทึก](https://assets.onproud.com/posts/2026/08/know-just-enough-git/commit-v1.jpg) *Commit คือ checkpoint หนึ่งจุดในประวัติ ไม่ใช่การส่งงานขึ้น GitHub หรือขึ้นเว็บ* ### ถ้าอยากย้อนกลับ หรือล้างงานทิ้ง เมื่อ commit คือ checkpoint คำถามเรื่องย้อนกลับก็ตอบง่ายขึ้น: **ย้อนได้ไกลเท่าที่เคยตั้ง checkpoint ไว้** | สถานะงาน | ถ้าล้างทิ้ง | |---|---| | **commit แล้ว** | ยังกู้กลับได้ เพราะมี checkpoint อยู่ | | **ยังไม่ commit** | หายจริง ไม่มีจุดให้กลับไป | เวลาย้อน เราไม่ต้องจำรหัสของ commit ก็ได้ อ้างด้วยใจความของงานได้เลย อยากย้อนกลับไปตอนก่อนเพิ่มปุ่มดาวน์โหลด บอกก่อนว่าจะย้อนไป commit ไหนและอะไรจะหาย ยังไม่ต้องทำ ให้ AI ยืนยันว่าจับถูก commit ก่อนทุกครั้ง เพราะประวัติอาจมีหลายจุดที่ใกล้กัน และนี่คือเหตุผลที่ commit message ควรเล่าได้ว่างานนั้นทำอะไร วันที่ต้องย้อน เราจะเรียกหามันด้วยชื่อ ไม่ใช่รหัส

เราเรียนรู้อะไร ดูชื่อ branch อ่าน diff ตรวจว่า commit message เล่าผลลัพธ์ของงานได้ และงานที่ commit แล้วยังย้อนกลับได้

เอาไปใช้ยังไง รู้ว่างานอยู่ถูกพื้นที่ ตรงขอบเขต และแก้ทางได้เมื่อ AI เดินผิดทิศ

 ## เมื่อจะขึ้นเว็บ: commit, push และ deploy เป็นคนละเหตุการณ์ ตอนนี้งานใหม่อยู่ใน commit บน `feature/download-cheat-sheet` แต่ถ้า GitHub Pages ของโปรเจกต์ publish จาก `main` เว็บจริงจะยังไม่เห็นงานนั้น ก่อน merge ให้ AI ตรวจ configuration ของโปรเจกต์ก่อนว่า deployment อ่านจาก branch ใด แล้วขอดู commit ที่กำลังจะเข้า `main` ตรวจ configuration แล้วแสดง commit ที่จะ merge จาก feature branch เข้า main ตรวจว่า main ไม่มีงานค้าง และรอฉันอนุมัติ หลัง merge แสดง status โดยยังไม่ push เช็กก่อนว่างานนี้ต้องเข้า branch ไหนถึงจะขึ้นเว็บ แล้วเตรียม merge ให้ผมดูก่อน เมื่อ merge แล้ว ประวัติของงานจึงกลับมาอยู่บน local `main` แต่ remote ยังไม่เปลี่ยนจนกว่าเราจะ push ![เส้น branch สีส้มโค้งกลับมารวมกับเส้น main สีเข้ม ก่อนเหลือเส้นเดียวเดินต่อ](https://assets.onproud.com/posts/2026/08/know-just-enough-git/merge-v1.jpg) *Merge นำประวัติของ branch ที่ตรวจแล้วกลับเข้ามารวมกับ `main`; หลังจุดรวม งานเดินต่อบนเส้นหลักเดียวกัน* เส้นทางเต็มของงานนี้คือ: ```text feature commit → merge main → push main → deployment → เปิด public URL ``` หลัง push ควรดูหน้า deployment และเปิด URL จริงเพื่อลอง flow ที่ผู้ใช้จะทำ ไม่ใช่หยุดที่ข้อความว่า deploy สำเร็จ จำไว้ว่า **push ไม่ได้แปลว่า deploy เสมอไป** บางโปรเจกต์ deploy จาก `main` บางโปรเจกต์ใช้ branch หรือขั้นตอนอื่น ต้องดู configuration ของโปรเจกต์นั้น

เราเรียนรู้อะไร งานบน feature branch ต้องกลับเข้า main หากระบบ deploy อ่านจาก main และ commit, push กับ deploy เป็นคนละสถานะ

เอาไปใช้ยังไง ตรวจต่อได้ว่างานเดินถึงขั้นไหน และบอกได้ว่าเวอร์ชันใดกำลังอยู่บนเว็บจริง

 ## เมื่อใช้กับคนอื่น: ไม่ push เข้า main ตรง แต่ส่งผ่าน Pull Request สมมติว่างานดาวน์โหลดขึ้นเว็บแล้ว งานต่อไปคือเพิ่มวิดีโอ YouTube ตอนนี้ลงในหน้า นี่เป็นงานคนละชิ้น จึงควรเปิด branch ใหม่ชื่อ `feature/add-youtube-video` เวลาทำงานร่วมกัน ปกติเราจะไม่ push เข้า `main` ตรง แม้ repository ยังอนุญาต เพราะ `main` เป็นเส้นหลักที่คนอื่นและระบบ deploy ใช้อ้างอิง เริ่มจากรับข้อมูลล่าสุดจาก remote แล้วสร้าง branch จาก `main` ล่าสุด: ตรวจว่างานสะอาด รับข้อมูลล่าสุดจาก remote แล้วรายงานว่า local main ตาม remote main ทันหรือไม่ ถ้าพร้อมให้สร้าง feature/add-youtube-video จาก main ล่าสุด และยืนยัน branch ก่อนแก้ เอา main ล่าสุดมา แล้วแยก branch เพิ่มวิดีโอให้หน่อย บอกผมก่อนเริ่มแก้ เมื่อเพิ่ม YouTube embed ตรวจ diff ทดลอง responsive และ commit แล้ว เรา push **branch งาน** ขึ้น GitHub จากนั้นเปิด Pull Request หรือ PR เข้า `main` ```text remote main ล่าสุด → branch งาน → commit → push branch → PR → review → merge ``` Pull Request ไม่ใช่เพียงปุ่มขอ merge แต่เป็นพื้นที่ให้ทุกคนเห็นว่าเปลี่ยนอะไร ทดสอบอย่างไร checks ผ่านหรือไม่ และยังมีอะไรควรตรวจก่อนแตะเส้นหลัก Push branch ปัจจุบันและเตรียม Pull Request เข้า main หัวข้อต้องบอกผลลัพธ์ รายละเอียดมีสิ่งที่เปลี่ยน วิธีทดสอบ และสิ่งที่ควรตรวจ แสดงร่างให้ฉันดูก่อนเปิด PR และห้าม merge ส่ง branch นี้ขึ้นไปและร่าง PR เข้า main ให้ดู ยังไม่ merge ถ้าหลาย branch แก้ตำแหน่งเดียวกัน Git อาจหยุดด้วย merge conflict มันไม่ได้แปลว่า repo พัง เพียงแต่ Git ไม่รู้ว่าคำตอบสุดท้ายควรเป็นแบบไหน อย่าสั่งเพียง “แก้ conflict ให้หน่อย” ลองใช้ว่า: อธิบายว่า conflict อยู่ไฟล์ใด branch ของเราเปลี่ยนอะไร main เปลี่ยนอะไร และมีทางรวมแบบใดบ้าง โดยยังไม่ resolve, commit หรือ push อธิบาย conflict สองฝั่งกับทางเลือกให้ฟังก่อน ยังไม่ต้องแก้

เราเรียนรู้อะไร การทำงานร่วมกันควรเริ่มจาก remote main ล่าสุด ทำงานบน branch แล้วส่งผ่าน PR ก่อน merge

เอาไปใช้ยังไง ทุกคนเห็นสิ่งที่จะเข้าเส้นหลัก และลดโอกาสที่งานหนึ่งจะทับงานของอีกคน

5 คำถามที่ต้องจำ

  1. สถานะมีงานเดิมค้างอยู่หรือไม่
  2. พื้นที่อยู่ branch ที่ถูกต้องและเริ่มจากเวอร์ชันล่าสุดหรือไม่
  3. ขอบเขตAI เปลี่ยนเฉพาะงานนี้หรือไม่
  4. หลักฐานดู diff และลอง flow จริงแล้วหรือยัง
  5. จุดหมายcommit, push หรือ merge นี้กำลังพางานไปที่ไหน

คุณไม่ต้องเป็น developer เพื่อใช้ Git ให้เป็น แค่ต้องมองงานให้ทันในจังหวะสำคัญ และรู้ว่าควรถาม AI อะไรก่อนให้มันทำขั้นต่อไป