SE บทที่ 5 — Git & GitHub · อ่านภาษารายงานของ AI ให้ออก
ใช้ปุ่ม ← → เปลี่ยนสไลด์ได้
SE TRACK — MODULE 5 · GIT & GITHUB
Git & GitHub — ศัพท์ที่ AI พูดใส่เราบ่อยที่สุด
ตอน AI ทำงานให้เรา มันจะรายงานว่า "I'll commit these changes and push to main" — ถ้าอ่านไม่ออก เราจะกดอนุมัติทั้งที่ไม่รู้ว่ามันกำลังทำอะไร บทนี้ทำให้ประโยคพวกนี้กลายเป็นภาษาที่เราอ่านออก ตอบถูก และคุมได้ — จบ 10 สไลด์นี้ ประโยคข้างบนจะอ่านออกทุกคำ
ไม่ต้องพิมพ์คำสั่ง Git เองแม้แต่บรรทัดเดียว — AI เป็นคนพิมพ์ให้ หน้าที่ของเราคืออ่านออกและตัดสินใจ
ของจริงจากหน้าจอ Ray — สั่งภาษาคนธรรมดา แล้ว AI รายงานกลับเป็นภาษา Git แบบนี้ทุกครั้ง
ทำไมต้องรู้
ไม่รู้ศัพท์กลุ่มนี้ = คุมงาน AI ไม่ได้
01 อ่านรายงาน AI ออกทุกครั้งที่ AI แตะโค้ด มันรายงานเป็นภาษา Git: commit, branch, push นี่คือ "ภาษารายงานตัวจริง" ของผู้ช่วยเรา — ทุกคำเดี๋ยวได้เรียนในบทนี้ 02 สั่งกลับได้ถูกคนรู้ศัพท์สั่งได้ว่า "แยก branch ก่อน แล้วเปิด Pull Request ให้ผมดู" คนไม่รู้ได้แต่พิมพ์ "โอเค" แล้วลุ้น 03 กล้าให้ AI ทดลองอะไรที่ commit เป็นจุดเซฟแล้ว ย้อนกลับได้เสมอ นี่คือเหตุผลที่ควรให้ AI commit บ่อย ๆ — แล้วเราจะกล้าปล่อยให้มันลองของใหม่
MENTAL MODEL ประจำบท
Git = ปุ่ม Save ที่ย้อนเวลาได้ · GitHub = ที่แชร์งาน + ห้องตรวจงาน
คู่แรกที่คนสับสนมากที่สุด
Git กับ GitHub ไม่ใช่สิ่งเดียวกัน
GIT · ในเครื่องเรา ตัวระบบเก็บประวัติเคยเซฟไฟล์เป็น "ใบเสนอราคา_v1", "_v2", "_ล่าสุดจริงๆ" ไหม? Git ทำสิ่งนั้นให้อัตโนมัติ เป็นระเบียบ และย้อนกลับไปดูได้ทุกเวอร์ชัน ทำงานได้โดยไม่ต้องต่อเน็ต อยู่ติดกับโปรเจกต์ในเครื่องเรา เก็บว่าใครแก้อะไร เมื่อไหร่ เพราะอะไร GITHUB · บนคลาวด์ ที่ฝากงาน + โต๊ะตรวจงานเว็บที่เอาโปรเจกต์ Git ขึ้นไปฝาก — เหมือน Google Drive ของงานโค้ด เพิ่มของที่ Git ไม่มี: ระบบขอให้ตรวจงานก่อนรวม + ระบบเช็คอัตโนมัติ (เดี๋ยวเจอชื่อจริงของมันในสไลด์ถัด ๆ ไป) เปิดดูงานจากมือถือหรือเบราว์เซอร์ได้ทุกที่ ไม่ต้องลงโปรแกรม
ซ้าย = Git สมุดประวัติในเครื่องเรา · ขวา = GitHub ตู้กลาง + โต๊ะตรวจงานบนคลาวด์ · ลูกศร = push ส่งงานขึ้นไป
จำง่าย ๆ: Git คือตัวระบบบันทึก · GitHub คือที่ฝาก + ที่ทำงานร่วมกัน — ต่อให้ลบบัญชี GitHub ทิ้ง ประวัติ Git ในเครื่องเราก็ยังอยู่ครบ
Mental model สำคัญที่สุดของบท
เส้นทางของงาน 1 ชิ้น — จากโต๊ะเรา ถึงตู้กลาง
WORKING TREE โต๊ะทำงาน ไฟล์ที่กำลังแก้อยู่ตอนนี้ — ยังไม่ได้บันทึกอะไรทั้งนั้น
git add → ↓
STAGING ถาด "จะบันทึก" คัดเฉพาะการแก้ที่จะรวมอยู่ในจุดเซฟรอบนี้
git commit → ↓
LOCAL REPO สมุดประวัติในเครื่อง จุดเซฟถูกบันทึกถาวร พร้อมข้อความว่าแก้อะไรเพราะอะไร
git push → ↓
REMOTE · GITHUB ตู้กลางบนคลาวด์ งานขึ้นคลาวด์ — คนอื่น (และ AI ตัวอื่น) มองเห็นแล้ว
ขากลับ: git pull = ดึงของใหม่จากตู้กลางมารวมกับงานในเครื่องเรา · ทำคนเดียวก็ต้องมีตู้กลาง — เพราะ "ทีม" ของเราคือเรา + AI และตู้กลางยังเป็น backup งานบนคลาวด์ไปในตัว
ศัพท์ชุดที่ 1 · 6 คำ
ฝั่ง "บันทึกงานในเครื่องเรา"
REPOSITORY · REPO บ้านของโปรเจกต์โค้ดทั้งหมด + ประวัติทุกจุดเซฟ รวมอยู่ในนี้ AI: "in this repo…" COMMIT จุดเซฟ 1 จุดบันทึกการแก้ พร้อมข้อความว่าแก้อะไร เพราะอะไร AI: "I'll commit these changes" BRANCH เส้นทางที่แยกออกมาทำฟีเจอร์/ทดลองของใหม่ โดยไม่แตะเส้นหลัก AI: "I'll create a feature branch" MAIN เส้นหลักของโปรเจกต์branch ที่ถือเป็น "เวอร์ชันจริงล่าสุด" (repo เก่าบางแห่งใช้ชื่อ master — ความหมายเดียวกัน) AI: "merge into main" STAGE · GIT ADD หยิบใส่ถาดเลือกการแก้ที่จะรวมเป็น commit รอบถัดไป AI: "I'll stage the changes" CLONE ดาวน์โหลดทั้งบ้านคัดลอก repo จาก GitHub ลงเครื่อง พร้อมประวัติครบ — เจอตอนเริ่มเครื่องใหม่ หรือให้ AI ดึงโปรเจกต์เดิมมาทำต่อ AI: "clone the repository"
ตัวอย่างจริง: AI แยก branch ชื่อ feature/promo-banner เพื่อทำแบนเนอร์โปรโมชันหน้าร้านออนไลน์ — หน้าเว็บจริงยังไม่โดนแตะจนกว่าเราจะอนุมัติให้รวมงาน
เส้นม่วงล่าง = main · เส้นฟ้าบน = branch ที่แยกไปทดลอง · จุดกลม = commit จุดเซฟ · จุดที่มี ✓ = merge กลับเข้าเส้นหลักหลังผ่านการตรวจ
ศัพท์ชุดที่ 2 · 6 คำ
ฝั่ง "ทำงานร่วมกันบนคลาวด์"
REMOTE · ORIGIN ที่อยู่ตู้กลางที่อยู่ของ repo บนคลาวด์ · "origin" คือชื่อเล่นมาตรฐานของตู้แรก AI: "push to origin" PUSH ส่งขึ้นคลาวด์ส่งจุดเซฟจากเครื่องขึ้น GitHub · push ขึ้น branch แยก = ยังไม่แตะ main · push ตรงเข้า main = เข้าเส้นหลักทันที AI: "I'll push the branch" PULL ดึงมา + รวมเลยดึงของใหม่จากคลาวด์ แล้วรวม เข้ากับงานในเครื่องเรา AI: "let me pull the latest changes" PULL REQUEST · PR ใบขอรวมงานขอรวมเข้า main พร้อมพื้นที่ให้ตรวจ คอมเมนต์ และรันระบบตรวจ ก่อนรวมจริง AI: "I'll open a PR" MERGE รวมงานรวมงานจาก branch หนึ่งเข้าอีก branch — ทีมส่วนใหญ่รวมผ่าน PR ให้มีคนตรวจก่อน AI: "once approved, I'll merge" MERGE CONFLICT งานชนกันสองสายแก้จุดเดียวกัน Git เลือกแทนไม่ได้ — ต้องมีคนเลือก AI: "there's a merge conflict"
ตัวอย่างจริง: AI push งานแบนเนอร์ขึ้น GitHub แล้วเปิด PR — เราเปิดมือถือดูได้เลยว่ามันแก้อะไร ก่อนกดรวม
⭐ หัวใจของบท
ตารางแปลภาษา AI — ได้ยินแบบนี้ ต้องทำยังไง
AI พูดว่า กำลังจะเกิดอะไร เราควรทำอะไร
"I'll create a feature branch" แยกเส้นทางใหม่ งานหลักไม่ถูกแตะ ✅ ปล่อยได้ — นี่คือวิธีทำงานที่ปลอดภัย "I'll commit these changes" บันทึกจุดเซฟในเครื่อง ยังไม่ขึ้นคลาวด์ ✅ ปกติ — commit บ่อย = ย้อนง่าย "I'll push the branch" ส่ง branch งานขึ้น GitHub — ยังไม่รวมเข้า main ✅ โอเค — งานขึ้นไปรอตรวจ "I'll open a pull request" ขอรวมเข้า main แบบมีจุดให้เราตรวจก่อน ✅ ดีที่สุด — เปิดดู diff (หน้าเทียบก่อน-หลัง: แดง = ที่ลบ เขียว = ที่เพิ่ม) ก่อนอนุมัติ "I'll revert that commit" สร้างจุดเซฟใหม่เพื่อลบผลของจุดเซฟเดิม — ประวัติไม่หาย ✅ วิธีย้อนงานที่ปลอดภัย "push directly to main" · "force push" · "reset --hard" เขียนเส้นหลักโดยไม่ผ่านตรวจ / เขียนทับประวัติ / ลบงานที่ยังไม่ commit ทิ้งจริง ⚠️ หยุดก่อน — สั่งให้แยก branch + เปิด PR หรือให้อธิบายก่อนว่าทำไมจำเป็น "there's a merge conflict" งานสองสายชนกัน ต้องมีคนเลือกว่าเอาฝั่งไหน 🟡 ไม่ใช่ของพัง — ให้ AI อธิบายตัวเลือกทั้งสองฝั่ง แล้วเราเคาะ
สูตรจำเร็ว: ประโยคที่มี branch / PR / revert = ทิศทางปลอดภัย · ประโยคที่มี directly to main / force / reset --hard = ยกมือถามก่อนเสมอ
กันหลงทาง
6 คู่ที่คนสับสนบ่อยที่สุด
คู่ศัพท์ ต่างกันตรงไหน
Save vs Commit Save = บันทึกไฟล์ทับของเดิม · Commit = เพิ่ม "จุดเซฟใหม่" เข้าประวัติ ย้อนกลับมาดูได้ตลอด Commit vs Push Commit อยู่แค่ในเครื่องเรา · Push ถึงจะส่งขึ้นคลาวด์ให้คนอื่นเห็น Fetch vs Pull Fetch = ดึงมาดูเฉย ๆ ยังไม่รวม · Pull = ดึงมาแล้วรวมเข้างานเราเลย Pull vs Pull Request pull = คำสั่ง sync ของในเครื่อง · Pull Request = ใบขอรวมงาน — คนละเรื่องกันเลย แค่ชื่อคล้าย Merge vs Deploy Merge = รวมโค้ดเข้าเส้นหลัก · Deploy = เอาของไปติดตั้งให้ระบบจริงรัน Main vs Production Main = branch หลักใน Git · Production = ระบบที่ลูกค้าใช้จริง — ปกติโค้ดใน main ยังไม่ถึงลูกค้าจนกว่าจะ deploy ยกเว้น โปรเจกต์ที่ตั้ง auto-deploy ไว้: merge เข้า main = ขึ้นเว็บจริงอัตโนมัติ (ถาม AI ได้ว่าโปรเจกต์เราตั้งแบบไหน)
ดูของจริง · 1
หน้าตา "บ้านโปรเจกต์ + สมุดประวัติ" ของจริง
หน้า Repo — เห็น branch main, 15 branches, รายการไฟล์ และ 89 commits = จุดเซฟสะสม 89 จุด
หน้า Commits — สมุดประวัติของจริง: ทุกจุดเซฟมีข้อความว่าแก้อะไร ใครทำ เมื่อไหร่ ย้อนดูได้หมด
สังเกต: ข้อความ commit เขียนโดย AI แต่มีชื่อ Ray กำกับคู่กัน — "Raysukezaa and claude committed" คือทีมเจ้าของร้าน + AI ตามที่เรียนมาทั้งบท
ดูของจริง · 2
หน้า Pull Request — "ใบขอรวมงาน" ของจริง
PR จริง 1 ใบ — ทุกส่วนที่เรียนมา อยู่ในหน้าเดียว
1 หัวใบขอรวมงาน สถานะ Open · "wants to merge 6 commits into main" — บอกครบว่าจะเอาอะไรรวมเข้าไหน
2 แท็บ Files changed = ที่ดู diff 17 ไฟล์ · +1,559 −110 บรรทัด — เขียว = เพิ่ม แดง = ลบ ตรงนี้คือด่านตรวจของเรา
3 Checks + "Ready to merge" ระบบตรวจผ่านแล้ว เหลือการตัดสินใจสุดท้าย — ปุ่ม Merge รอเรา เป็นคนเคาะ
Workflow มาตรฐาน
วงจร "รวมเข้า main" — ใครทำขั้นไหน
1 แยก branch ใหม่ AI ทำ งานหลักปลอดภัยตั้งแต่ขั้นแรก
2 แก้โค้ด + commit จุดเซฟเล็ก ๆ AI ทำ เซฟถี่ ๆ ย้อนง่าย
3 Push ขึ้น GitHub AI ทำ งานขึ้นคลาวด์ รอการตรวจ
4 เปิด Pull Request AI ทำ สร้าง "ใบขอรวมงาน" พร้อมสรุปว่าแก้อะไร
5 Review — อ่าน diff 🙋 เราทำ หน้าเทียบก่อน-หลัง: แดง = ที่ลบ เขียว = ที่เพิ่ม — ด่านมนุษย์ด่านแรก
6 รอ Checks เขียว ระบบทำ ระบบตรวจอัตโนมัติของ GitHub · เขียว = ผ่าน · แดง = บอก AI ให้ไปดูว่าพังตรงไหน
7 กด Merge 🙋 เราเคาะ การตัดสินใจรวมเข้าเส้นหลัก เป็นของเรา
8 ลบ branch เก่า + อัปเดตในเครื่อง AI ทำ เก็บกวาดปิดงาน
หลักจำ: "AI ร่าง — คนเซ็น" · AI ทำ 6 ขั้นที่เป็นแรงงาน แต่ 2 ขั้นที่เป็น "การตัดสินใจ" (Review + Merge) เป็นของเราเสมอ
QUICK-CHECK · กดดูเฉลย
จริงหรือไม่? — เช็คก่อนปิดบท
1 · "Push แล้ว ลูกค้าเห็นของใหม่ทันที"
ไม่จริง — push แค่ส่งงานขึ้น GitHub · กว่าจะถึงลูกค้าต้องผ่าน merge เข้า main แล้ว deploy อีกขั้น · ข้อยกเว้น: โปรเจกต์ที่ตั้ง auto-deploy ไว้ merge ปุ๊บขึ้นเว็บจริงปั๊บ — ต้องรู้ว่าโปรเจกต์เราตั้งแบบไหน (ถาม AI ได้เลย)
2 · "ให้ AI commit บ่อย ๆ เดี๋ยวประวัติรกเปล่า ๆ"
ไม่จริง — commit คือจุดเซฟ ยิ่งถี่ยิ่งย้อนกลับได้ละเอียด งานที่ยังไม่ commit ต่างหากที่หายได้จริง
3 · "Merge conflict แปลว่าโค้ดพังแล้ว"
ไม่จริง — แค่งานสองสายแก้จุดเดียวกัน Git เลยตัดสินใจแทนเราไม่ได้ ต้องมีคนเลือก
KEY TAKEAWAY
Branch = แยกเส้นทางปลอดภัย · Commit = จุดเซฟ · Push = ส่งขึ้นคลาวด์ · PR = ใบขอรวมแบบมีคนตรวจ"Push ไม่ใช่ Deploy — AI เขียนโค้ดได้ แต่คนเป็นคนกดรวม"
← ก่อนหน้า
1 / 12
ถัดไป →
