GitHub คืออะไร? คู่มือใช้ GitHub และคำสั่ง Git ตั้งแต่พื้นฐานถึงระดับสูง
GitHub ไม่ใช่แค่ที่ฝากโค้ด แต่เป็นระบบจัดการเวอร์ชัน งานทีม รีวิวโค้ด ติดตาม issue และปล่อยงานขึ้น production คู่มือนี้สรุปให้ตั้งแต่ GitHub คืออะไร คำศัพท์ที่ต้องเจอ ไปจนถึงคำสั่ง Git ที่ใช้จริงในชีวิตประจำวัน ทั้ง clone, add, commit, branch, pull, push, merge, rebase, stash, tag, revert และ reset
ระดับ
เริ่มต้นถึงสูง
เวลาอ่าน
18 นาที
Format
Action guide
Editorial note
MIMO รวบรวมคู่มือ AI และเครื่องมือดิจิทัลสำหรับผู้ใช้ภาษาไทย เนื้อหาอ้างอิงจากข้อมูลที่เผยแพร่โดย vendor ข้อมูลที่เปิดเผยต่อสาธารณะ และการวิเคราะห์เชิง workflow ก่อนสมัครหรือซื้อบริการใด ๆ ควรตรวจราคา เงื่อนไข และรายละเอียดล่าสุดจากผู้ให้บริการโดยตรง
Tags
เหมาะกับใคร?
คนเริ่มเขียนโค้ดที่เห็นคำว่า GitHub, repo, commit, branch, PR แล้วงงว่าแต่ละอย่างคืออะไร
เจ้าของเว็บหรือโปรเจกต์ที่ใช้ AI/Codex/Claude ช่วยแก้โค้ด และอยากเข้าใจว่าควรตรวจงานผ่าน GitHub ยังไง
คนทำงานคนเดียวที่อยากเก็บประวัติการแก้ไฟล์ เผื่อย้อนกลับเมื่อเว็บพังหรือแก้ผิดทาง
ทีมเล็กที่อยากเริ่ม workflow แบบ branch, pull request, review, merge และ deploy ให้เป็นระบบขึ้น
ก่อนเริ่มควรรู้
Git กับ GitHub ไม่ใช่สิ่งเดียวกัน: Git คือเครื่องมือจัดการประวัติไฟล์ในเครื่อง ส่วน GitHub คือเว็บ/แพลตฟอร์มที่เอา repo ไปฝาก แชร์ รีวิว และทำงานร่วมกัน
ก่อนใช้คำสั่ง Git ให้ติดตั้ง Git และตั้งชื่อกับอีเมลด้วย `git config --global user.name` และ `git config --global user.email` เพราะข้อมูลนี้จะติดไปกับ commit
อย่า commit secret เช่น API key, database password, private key, token หรือไฟล์ `.env` ลง repo แม้ repo จะเป็น private ก็ตาม
ถ้ายังไม่มั่นใจคำสั่งที่แก้ history เช่น `reset --hard`, `rebase`, `push --force` ให้หยุดอ่านผลลัพธ์ก่อนกด Enter เพราะคำสั่งกลุ่มนี้อาจทำงานหายหรือทำให้ branch ทีมสับสนได้
สรุปเร็ว
Point 1
เข้าใจก่อนว่า GitHub คือที่เก็บ repo และ workflow ส่วน Git คือเครื่องมือเก็บประวัติการแก้ไฟล์ในเครื่อง
Point 2
เริ่มจาก clone repo ลงเครื่อง สร้าง branch ใหม่ แก้ไฟล์ ตรวจ diff แล้ว commit เป็นก้อนงานเล็ก ๆ
Point 3
ใช้ pull เพื่อดึงงานล่าสุดจาก GitHub และใช้ push เพื่อส่ง commit ของเราขึ้น remote branch
Point 4
เปิด Pull Request เพื่อให้เห็น diff, คุยงาน, review และ merge เข้า branch หลักอย่างเป็นระบบ
Point 5
ใช้ issue สำหรับเก็บ bug/task/idea และ link PR เข้ากับ issue เพื่อให้รู้ว่างานไหนกำลังถูกแก้
Point 6
เมื่อคล่องแล้วค่อยเรียนคำสั่งขั้นกลาง เช่น stash, rebase, cherry-pick, tag, revert, reset, reflog และ bisect
Point 7
วางกฎทีมให้ชัด: ห้าม push เข้า main ตรง ๆ, ต้องเปิด PR, ต้องผ่าน test/build, และต้องไม่ใส่ secret ลง repo
GitHub คืออะไรแบบเข้าใจง่าย
GitHub คือแพลตฟอร์มสำหรับเก็บโค้ดและไฟล์โปรเจกต์แบบมีประวัติการแก้ไข ทุกครั้งที่คุณแก้ไฟล์แล้ว commit ระบบจะจำว่าเปลี่ยนอะไร ใครเปลี่ยน เมื่อไหร่ และเปลี่ยนเพราะอะไร ทำให้ย้อนดูหรือย้อนแก้ได้ง่ายกว่าเก็บไฟล์เป็น project-final-final-v3.zip
สำหรับคนทำเว็บหรือทำแอป GitHub ยังเป็นศูนย์กลางการทำงานร่วมกัน เช่น เปิด issue เก็บงาน เปิด pull request ให้ตรวจโค้ดก่อนรวมเข้า main ใช้ GitHub Actions รัน test/build อัตโนมัติ และเชื่อมกับ Vercel/Netlify เพื่อ deploy เว็บจาก repo ได้
ใช้ฝากโค้ดและไฟล์โปรเจกต์แบบมี version history
ใช้ทำงานร่วมกันผ่าน branch, pull request, review และ issue
ใช้เป็นจุดเชื่อมกับ CI/CD เช่น test, build, deploy
เหมาะทั้งคนทำคนเดียวและทีมใหญ่ เพราะช่วยให้รู้ว่าอะไรเปลี่ยนและย้อนกลับได้
Git กับ GitHub ต่างกันยังไง
Git คือโปรแกรม version control ที่รันในเครื่องของเรา ใช้บันทึกประวัติไฟล์ สร้าง branch รวม branch และย้อนดูการเปลี่ยนแปลงได้ ส่วน GitHub คือบริการออนไลน์ที่ host repo Git และเพิ่มฟีเจอร์การทำงานร่วมกัน เช่น Pull Request, Issue, Project, Actions, Release และ Wiki
จำง่าย ๆ คือ Git เป็นเครื่องมือ ส่วน GitHub เป็นบ้านกลางของโปรเจกต์ คุณสามารถใช้ Git โดยไม่มี GitHub ได้ และสามารถมี repo อยู่บนบริการอื่นเช่น GitLab หรือ Bitbucket ได้ แต่ GitHub เป็นที่นิยมมากเพราะ ecosystem กว้างและเชื่อมกับเครื่องมือ dev จำนวนมาก
Git = เครื่องมือจัดการประวัติไฟล์ในเครื่อง
GitHub = เว็บสำหรับฝาก repo, review งาน, track issue และ collaborate
Local repository = repo ในเครื่องเรา
Remote repository = repo บน GitHub หรือ server อื่น
คำศัพท์ GitHub ที่ต้องเจอบ่อย
ถ้าเพิ่งเริ่มใช้ GitHub สิ่งที่ทำให้หลงที่สุดไม่ใช่คำสั่ง แต่คือศัพท์ที่โผล่มาพร้อมกันเยอะมาก ตารางสั้น ๆ นี้คือกลุ่มคำที่ควรรู้ก่อนเริ่มทำงานจริง
ไม่ต้องจำทั้งหมดในวันแรก ให้จำภาพรวมก่อนว่า repo คือที่เก็บงาน commit คือจุดบันทึก branch คือพื้นที่ทดลอง PR คือคำขอรวมงาน และ merge คือการเอางานกลับเข้ากิ่งหลัก
Repository / Repo: โฟลเดอร์โปรเจกต์ที่มีไฟล์และประวัติการแก้ไข
Commit: จุดบันทึกการเปลี่ยนแปลงหนึ่งชุด ควรเขียน message ให้บอกเหตุผลหรือสิ่งที่เปลี่ยน
Branch: กิ่งงานแยกจาก main เพื่อทดลองหรือทำฟีเจอร์โดยไม่กระทบตัวหลัก
Main / Master: branch หลักของ repo ปัจจุบันนิยมใช้ `main`
Remote: repo ปลายทางบน GitHub เช่น `origin`
Clone: ดาวน์โหลด repo จาก GitHub ลงเครื่องแบบมีประวัติครบ
Fork: copy repo ของคนอื่นมาอยู่ในบัญชีเรา เพื่อแก้ต่อโดยไม่กระทบต้นฉบับ
Pull Request / PR: คำขอรวมงานจาก branch หนึ่งไปอีก branch พร้อมหน้า review diff
Merge: รวมการเปลี่ยนแปลงจาก branch หนึ่งเข้าอีก branch
Conflict: สถานการณ์ที่ Git รวมไฟล์เองไม่ได้ เพราะแก้บรรทัดเดียวกันหรือใกล้กัน ต้องให้คนตัดสินใจ
Issue: ticket สำหรับ bug, task, idea หรือคำถาม
Release: จุดปล่อยเวอร์ชัน เช่น v1.0.0 พร้อม changelog และไฟล์ build
Tag: ป้ายชื่อชี้ไปที่ commit สำคัญ มักใช้กับ version release
GitHub Actions: ระบบ automation/CI/CD เช่น run test, build, deploy
README: ไฟล์แนะนำโปรเจกต์ วิธีติดตั้ง ใช้งาน และข้อมูลสำคัญของ repo
Workflow พื้นฐานที่ใช้จริงทุกวัน
workflow ที่ปลอดภัยสำหรับมือใหม่คืออย่าแก้บน main ตรง ๆ ให้เริ่มจากดึงงานล่าสุด สร้าง branch แยก แก้ไฟล์ commit push แล้วเปิด PR วิธีนี้ทำให้ main ยังสะอาด และถ้าแก้ผิดก็ทิ้ง branch ได้โดยไม่กระทบงานหลัก
ถ้าทำงานคนเดียว workflow นี้อาจดูเยอะในตอนแรก แต่พอเว็บหรือแอปเริ่มจริงจัง การมี branch และ PR จะช่วยให้คุณตรวจ diff ก่อน merge และรู้ได้ว่าวันนี้เปลี่ยนอะไรไปบ้าง
1. `git switch main` เพื่อกลับไป branch หลัก
2. `git pull origin main` เพื่อดึงงานล่าสุด
3. `git switch -c feature/github-guide` เพื่อสร้าง branch ใหม่
4. แก้ไฟล์ แล้วใช้ `git status` และ `git diff` ตรวจงาน
5. `git add .` แล้ว `git commit -m "Add GitHub guide"` เพื่อบันทึก
6. `git push -u origin feature/github-guide` เพื่อส่ง branch ขึ้น GitHub
7. เปิด Pull Request บน GitHub ตรวจ diff แล้ว merge เมื่อพร้อม
คำสั่งเริ่มต้น: setup และ clone repo
คำสั่งกลุ่มแรกคือ setup ตัวตนและเอา repo ลงเครื่อง ใช้ครั้งแรกไม่กี่คำสั่ง แต่สำคัญมาก เพราะ commit จะผูกกับชื่อและอีเมลที่ตั้งไว้
ถ้า clone ด้วย HTTPS ระบบอาจให้ login/token ส่วนถ้าใช้ SSH ต้องสร้าง SSH key และเพิ่ม public key ใน GitHub ก่อน วิธีไหนก็ได้ เลือกแบบที่สะดวกและองค์กรอนุญาต
`git --version` ตรวจว่าติดตั้ง Git แล้วหรือยัง
`git config --global user.name "Your Name"` ตั้งชื่อผู้ commit
`git config --global user.email "[email protected]"` ตั้งอีเมลผู้ commit
`git config --list` ดู config ปัจจุบัน
`git clone https://github.com/owner/repo.git` ดาวน์โหลด repo ลงเครื่อง
`git remote -v` ดูว่า repo นี้เชื่อมกับ remote ไหน
`git remote add origin <url>` เพิ่ม remote ให้ repo ที่สร้างเองในเครื่อง
คำสั่งทำงานประจำ: status, diff, add, commit
ก่อน commit ทุกครั้งควรดู status และ diff เพราะนี่คือจุดที่ช่วยกันพลาดได้ดีที่สุด `status` บอกว่าไฟล์ไหนเปลี่ยน ส่วน `diff` บอกว่าเปลี่ยนบรรทัดไหน
commit ที่ดีควรเล็กพอให้ review ง่ายและมี message ชัด เช่น Add login validation, Fix webhook signature check, Update GitHub guide ไม่ควร commit ทุกอย่างปนกันเป็นก้อนเดียวถ้าไม่จำเป็น
`git status` ดูสถานะไฟล์ว่าแก้ เพิ่ม ลบ หรือ staged แล้วหรือยัง
`git diff` ดูสิ่งที่เปลี่ยนแต่ยังไม่ได้ staged
`git diff --staged` ดูสิ่งที่จะเข้า commit ถ้ากด commit ตอนนี้
`git add file.ts` เลือก stage เฉพาะไฟล์
`git add .` stage ทุกไฟล์ที่เปลี่ยนในโฟลเดอร์ปัจจุบัน ต้องใช้ด้วยความระวัง
`git commit -m "message"` สร้าง commit พร้อมข้อความสั้น
`git commit --amend` แก้ commit ล่าสุด เช่น แก้ message หรือเพิ่มไฟล์ที่ลืม stage ก่อน push
คำสั่ง branch: แยกงานไม่ให้ชน main
branch คือหัวใจของ GitHub workflow เพราะช่วยให้คุณทำฟีเจอร์ แก้บั๊ก หรือทดลองของใหม่โดยไม่แตะ main จนกว่างานจะพร้อม merge
ตั้งชื่อ branch ให้สื่อความหมาย เช่น `feature/member-dashboard`, `fix/login-oauth`, `content/github-guide` จะช่วยให้หน้า PR และ history อ่านง่ายขึ้น
`git branch` ดู branch ทั้งหมดในเครื่อง
`git switch branch-name` ย้ายไป branch ที่มีอยู่แล้ว
`git switch -c new-branch` สร้าง branch ใหม่และย้ายเข้าไปทันที
`git branch -m new-name` เปลี่ยนชื่อ branch ปัจจุบัน
`git branch -d branch-name` ลบ branch ในเครื่องหลัง merge แล้ว
`git push -u origin branch-name` ส่ง branch ใหม่ขึ้น GitHub และตั้ง upstream
`git fetch --prune` อัปเดตรายชื่อ branch จาก remote และลบ reference ที่ remote ลบไปแล้ว
คำสั่ง sync กับ GitHub: fetch, pull, push
คำสั่ง sync คือสะพานระหว่างเครื่องเรากับ GitHub ถ้าไม่เข้าใจกลุ่มนี้ จะเจอปัญหา classic เช่น ทำไมเครื่องเราไม่มี commit ล่าสุด ทำไม push ไม่ได้ หรือทำไม branch บน GitHub ไม่ตรงกับในเครื่อง
จำง่าย ๆ: `fetch` คือเช็กของใหม่แต่ยังไม่รวมเข้าไฟล์เรา, `pull` คือ fetch แล้วรวมเข้ามา, `push` คือส่ง commit ของเราขึ้น remote
`git fetch origin` ดึงข้อมูลล่าสุดจาก GitHub แต่ยังไม่ merge เข้า branch ปัจจุบัน
`git pull origin main` ดึงและรวม commit ล่าสุดจาก remote main เข้ามา
`git push origin branch-name` ส่ง commit ใน branch ขึ้น GitHub
`git push` ใช้ได้เมื่อ branch ตั้ง upstream แล้ว
`git pull --rebase origin main` ดึง main ล่าสุดแล้ววาง commit ของเราทับด้านบน ช่วยให้ history เป็นเส้นตรงขึ้น
ถ้า push ไม่ได้เพราะ remote มีงานใหม่ ให้ pull/rebase ก่อน แล้วค่อย push ใหม่
Pull Request ใช้ทำอะไร
Pull Request คือหน้าที่เอาไว้เสนอการเปลี่ยนแปลงจาก branch หนึ่งไปอีก branch โดยปกติคือจาก feature branch เข้า main จุดสำคัญของ PR คือทำให้เห็น diff, คุยเหตุผล, review, run checks และ merge แบบมีร่องรอย
สำหรับคนทำคนเดียว PR ยังมีประโยชน์มาก เพราะเป็นจุด pause ก่อนเอาโค้ดเข้า main คุณจะเห็นว่าตัวเองแก้อะไรบ้าง ลืมไฟล์ไหนไหม และ test/build ผ่านหรือเปล่า
PR title ควรบอกผลลัพธ์ เช่น `Add GitHub basics guide`
PR description ควรบอกว่าเปลี่ยนอะไร ทำไม และตรวจอะไรแล้ว
ถ้า PR แก้ issue ให้เขียน `Closes #123` เพื่อปิด issue อัตโนมัติเมื่อ merge
ดู Files changed ก่อน merge ทุกครั้ง โดยเฉพาะไฟล์ env, config, auth, payment, database
ถ้ามี CI ให้รอ checks ผ่านก่อน merge
หลัง merge แล้วลบ branch ที่ไม่ใช้ เพื่อให้ repo สะอาด
จัดการ conflict อย่างใจเย็น
conflict เกิดเมื่อ Git ตัดสินใจเองไม่ได้ว่าควรใช้เวอร์ชันไหน เช่น คุณกับคนอื่นแก้บรรทัดเดียวกันในไฟล์เดียวกัน Git จะใส่ marker อย่าง `<<<<<<<`, `=======`, `>>>>>>>` ให้เราเลือกแก้
วิธีแก้คือเปิดไฟล์ที่ conflict เลือกเนื้อหาที่ถูกต้อง ลบ marker ออก รัน test/build แล้ว commit ผลการ resolve อย่ากดสุ่ม accept all incoming/current ถ้ายังไม่เข้าใจว่ากำลังทิ้งโค้ดฝั่งไหน
`git status` ดูไฟล์ที่ conflict
เปิดไฟล์แล้วหา marker `<<<<<<<` เพื่อเลือกเวอร์ชันที่ถูกต้อง
แก้ไฟล์ให้เหลือโค้ดจริง ไม่มี marker conflict
`git add file` เพื่อ mark ว่า resolve แล้ว
`git commit` หรือ `git rebase --continue` ตาม workflow ที่กำลังทำ
ถ้าหลงทางระหว่าง merge ใช้ `git merge --abort` เพื่อยกเลิก merge ได้
ถ้าหลงทางระหว่าง rebase ใช้ `git rebase --abort` เพื่อกลับก่อน rebase
คำสั่ง undo ที่ควรรู้: restore, revert, reset
Git มีคำสั่งย้อนหลายแบบและชื่อคล้ายกันมาก จุดที่ต้องจำคือ `restore` ใช้กับไฟล์, `revert` สร้าง commit ใหม่เพื่อย้อนผลของ commit เก่า และ `reset` ขยับ pointer/history ของ branch ซึ่งอันตรายกว่าถ้าใช้ผิด
ถ้า commit ถูก push ขึ้น GitHub และมีคนอื่นใช้งานแล้ว โดยทั่วไปควรใช้ `git revert` แทน `git reset` เพราะ revert ไม่แก้ history เก่า แต่สร้าง commit ใหม่ที่ย้อนผลลัพธ์ ทำให้ทีมตาม history ได้ปลอดภัยกว่า
`git restore file.ts` ย้อนไฟล์ที่ยังไม่ได้ stage กลับไปเหมือน commit ล่าสุด
`git restore --staged file.ts` เอาไฟล์ออกจาก staging แต่ยังเก็บการแก้ไว้ใน working tree
`git revert <commit>` สร้าง commit ใหม่ที่ย้อนการเปลี่ยนแปลงของ commit นั้น
`git reset --soft HEAD~1` ย้อน commit ล่าสุดแต่เก็บไฟล์ไว้ใน staged state
`git reset --mixed HEAD~1` ย้อน commit ล่าสุดและเอาไฟล์ออกจาก staged แต่ยังเก็บการแก้ไว้
`git reset --hard HEAD~1` ย้อน commit และทิ้งการแก้ใน working tree ใช้ด้วยความระวังมาก
ถ้าทำพลาด ให้รีบดู `git reflog` เพื่อหา commit เก่าที่อาจกู้กลับได้
คำสั่งระดับกลางถึงสูง: stash, rebase, cherry-pick, tag
เมื่อใช้ GitHub ไปสักพัก คุณจะเจอสถานการณ์ที่ต้องพักงานชั่วคราว จัด history ให้เรียบร้อย ดึง commit บางตัวข้าม branch หรือทำ release version คำสั่งกลุ่มนี้ช่วยได้ แต่ควรเข้าใจผลลัพธ์ก่อนใช้
กฎง่าย ๆ คือ rebase และ force push ควรใช้กับ branch ส่วนตัวหรือ branch ที่ทีมตกลงกันแล้วเท่านั้น อย่า rewrite history ของ branch ที่คนอื่นกำลัง base งานอยู่โดยไม่บอกทีม
`git stash` พักการแก้ปัจจุบันไว้ชั่วคราว เพื่อสลับ branch หรือ pull งานล่าสุด
`git stash pop` เอางานที่ stash ไว้กลับมาและลบออกจาก stash list
`git stash list` ดู stash ทั้งหมด
`git rebase main` เอา commit ของ branch ปัจจุบันไปวางต่อจาก main ล่าสุด ทำให้ history เป็นเส้นตรง
`git rebase -i HEAD~3` จัดการ commit ล่าสุด 3 ตัว เช่น squash, reword, reorder
`git cherry-pick <commit>` ดึง commit หนึ่งจาก branch อื่นมาใช้ใน branch ปัจจุบัน
`git tag v1.0.0` สร้าง tag สำหรับเวอร์ชัน
`git push origin v1.0.0` ส่ง tag ขึ้น GitHub
`git log --oneline --graph --decorate --all` ดู history แบบเห็น branch และ tag ชัดขึ้น
คำสั่งตรวจสอบและไล่บั๊ก history
เวลาเว็บพังหลังแก้โค้ดหรือไม่รู้ว่าใครเปลี่ยนบรรทัดไหน Git ช่วยสืบได้ดีมาก คำสั่งกลุ่ม inspect/debug ทำให้เราไม่ต้องเดาสุ่มจากความจำ
สำหรับทีมเล็กหรือคนทำคนเดียว `log`, `show`, `blame`, `grep`, `bisect` คือชุดคำสั่งที่ช่วยหาต้นตอได้เร็วขึ้น โดยเฉพาะเมื่อมี commit เยอะแล้ว
`git log --oneline` ดูรายการ commit แบบสั้น
`git show <commit>` ดูรายละเอียด commit หนึ่งตัว
`git blame file.ts` ดูว่าแต่ละบรรทัดมาจาก commit ไหนและใครแก้
`git grep "keyword"` ค้นข้อความใน repo ด้วย Git
`git bisect start` เริ่มหา commit ที่ทำให้ bug เกิดแบบ binary search
`git bisect good <commit>` บอก commit ที่ยังดี
`git bisect bad <commit>` บอก commit ที่มี bug
`git bisect reset` ออกจากโหมด bisect หลังหาเสร็จ
ไฟล์สำคัญใน repo ที่ควรรู้จัก
repo ที่ดีไม่ได้มีแค่ source code แต่ควรมีไฟล์ประกอบที่ทำให้คนอื่นเข้าใจ ติดตั้ง ใช้งาน ร่วมพัฒนา และ deploy ได้ง่ายขึ้น ไฟล์เหล่านี้ช่วยลดคำถามซ้ำและลดความเสี่ยงในทีม
สำหรับโปรเจกต์ที่ใช้ AI ช่วยเขียนโค้ด ไฟล์ README, CONTRIBUTING, .env.example และ test/build script สำคัญมาก เพราะ AI และคนจะใช้เป็นบริบทในการทำงานต่อ
`README.md`: แนะนำโปรเจกต์ วิธีติดตั้ง วิธีรัน และข้อมูลหลัก
`.gitignore`: บอก Git ว่าไฟล์ไหนไม่ต้อง track เช่น node_modules, .env, build output
`.env.example`: ตัวอย่างชื่อ env ที่ต้องตั้ง โดยไม่ใส่ secret จริง
`LICENSE`: บอกสิทธิ์การใช้โค้ด
`CONTRIBUTING.md`: แนวทางส่ง PR, style, test และ review
`CHANGELOG.md`: บันทึกการเปลี่ยนแปลงแต่ละเวอร์ชัน
`.github/workflows/*.yml`: GitHub Actions workflow สำหรับ test/build/deploy
`.github/pull_request_template.md`: template ให้ PR มีข้อมูลครบ
GitHub สำหรับคนใช้ AI เขียนโค้ด
ยุคนี้หลายคนใช้ AI agent ช่วยแก้โค้ด แต่ GitHub ยังสำคัญกว่าเดิม เพราะเป็นระบบกันพลาดและตรวจงานของ AI ถ้า AI แก้ผิด คุณต้องเห็น diff, เข้าใจ commit, run test และ revert ได้
ให้คิดว่า AI เป็นคนช่วยพิมพ์และช่วยคิด แต่ GitHub เป็นสมุดบัญชีว่าเกิดอะไรขึ้นกับโปรเจกต์ ถ้าไม่มี commit ที่ดี ไม่มี PR ที่อ่านได้ และไม่มี CI ตรวจ งานที่ AI ทำเร็วอาจกลายเป็นความเสี่ยงเร็วเหมือนกัน
ให้ AI ทำงานบน branch แยกเสมอ ไม่แก้ main ตรง ๆ
ขอให้ AI สรุปไฟล์ที่แก้ เหตุผล และวิธีทดสอบใน PR description
อ่าน diff เองก่อน merge โดยเฉพาะ auth, payment, env, database, security และ deploy config
อย่าให้ AI commit secret หรือไฟล์ .env จริงขึ้น repo
ถ้า AI เปลี่ยนหลายเรื่องใน commit เดียว ให้แยก commit หรือแยก PR เพื่อ review ง่ายขึ้น
ใช้ `git revert` หรือ PR rollback เมื่อ merge แล้วพบว่าเว็บพัง
Checklist ก่อน push หรือ merge
ก่อนส่งงานขึ้น GitHub หรือ merge PR ให้ใช้ checklist สั้น ๆ เพื่อกันปัญหาแบบที่เจอบ่อย เช่น commit ไฟล์ผิด ลืมรัน build ใส่ secret ลง repo หรือแก้ main โดยไม่ตั้งใจ
ถ้าทำเว็บ production อย่าง MIMO, Loopmi หรือโปรเจกต์ลูกค้า checklist นี้ควรเป็นนิสัย เพราะการ merge หนึ่งครั้งอาจไป trigger deploy จริงทันที
รัน `git status` แล้วไม่มีไฟล์แปลก ๆ เช่น `.env`, log, backup, zip, screenshot ส่วนตัว
รัน `git diff --staged` เพื่อดูสิ่งที่จะ commit จริง
commit message อ่านรู้เรื่อง ไม่ใช่ `update`, `fix`, `asdf` ถ้าเป็นงานสำคัญ
รัน test/typecheck/build เท่าที่โปรเจกต์มี เช่น `npm run build` หรือ `npm run typecheck`
PR description บอกว่าเปลี่ยนอะไร ทำไม และตรวจอะไรแล้ว
ไม่มี API key, token, password, private key หรือ service role key ใน diff
ถ้าแก้ database/migration/payment/auth ต้องอ่าน diff ซ้ำอย่างช้า ๆ ก่อน merge
หลัง merge เช็ก deploy และหน้าเว็บจริงถ้า branch main ผูกกับ production
ตารางตัดสินใจเร็ว
โจทย์
Git vs GitHub
ตัวเลือกหลัก
Git คือเครื่องมือ version control
GitHub คือแพลตฟอร์ม host repo และทำงานร่วมกันผ่าน PR, issue, actions และ review
ใช้ Git ในเครื่อง แล้ว push งานขึ้น GitHub
โจทย์
Commit vs Push
ตัวเลือกหลัก
Commit บันทึกงานในเครื่อง
Push ส่ง commit จากเครื่องขึ้น remote บน GitHub
commit แล้วคนอื่นยังไม่เห็น จนกว่าจะ push
โจทย์
Fetch vs Pull
ตัวเลือกหลัก
Fetch ดึงข้อมูล remote มาเช็กก่อน
Pull คือ fetch แล้วรวมเข้า branch ปัจจุบัน
ถ้าอยากดูของใหม่โดยยังไม่แตะไฟล์ ใช้ fetch
โจทย์
Merge vs Rebase
ตัวเลือกหลัก
Merge รวม branch โดยสร้าง merge commit หรือ fast-forward
Rebase ย้ายฐาน commit ให้ history เป็นเส้นตรงกว่า แต่ rewrite history ได้
มือใหม่ใช้ merge ก่อน เมื่อเข้าใจ history ค่อยใช้ rebase
โจทย์
Revert vs Reset
ตัวเลือกหลัก
Revert สร้าง commit ใหม่เพื่อย้อนผลลัพธ์
Reset ขยับ branch pointer และอาจแก้ history หรือทิ้งงาน
งานที่ push แล้วและทีมใช้อยู่ควร revert มากกว่า reset
โจทย์
Branch vs Fork
ตัวเลือกหลัก
Branch คือกิ่งงานใน repo เดียวกัน
Fork คือ copy repo ไปอยู่ในบัญชีเรา มักใช้เมื่อไม่มีสิทธิ์เขียน repo ต้นฉบับ
ทีมภายในใช้ branch ส่วน open source มักใช้ fork + PR
กฎตัดสินใจ
ถ้ากำลังแก้ฟีเจอร์หรือบทความใหม่ ให้สร้าง branch ใหม่จาก main ก่อนเสมอ
ถ้าการแก้ยังไม่ถูก push และเป็น branch ส่วนตัว คุณสามารถ amend/rebase เพื่อจัด commit ให้สวยได้
ถ้า commit ถูก push แล้วและมีคนอื่นใช้งาน branch นั้น ให้หลีกเลี่ยง reset/rebase/force push เว้นแต่ตกลงกับทีมแล้ว
ถ้าต้องย้อนงานที่ merge เข้า main แล้ว ให้เริ่มจาก revert PR หรือ revert commit ก่อน อย่า reset main
ถ้าจะใช้ AI agent แก้โค้ด ให้บังคับให้ทำผ่าน branch + PR + diff review ไม่ใช่แก้ production ตรง ๆ
ถ้า repo มีข้อมูลลูกค้า เงิน หรือระบบ login ให้ตั้ง branch protection และ CI ก่อนปล่อยให้หลายคน push
ข้อผิดพลาดที่ควรเลี่ยง
แก้ไฟล์บน main ตรง ๆ แล้ว push เข้า production โดยไม่ได้เปิด PR
ใช้ `git add .` แล้วเผลอ commit ไฟล์ `.env`, log, zip, database dump หรือไฟล์ส่วนตัว
เขียน commit message กว้างเกินไป เช่น `update` ทำให้ย้อนดู history ไม่รู้เรื่อง
ไม่ pull main ล่าสุดก่อนสร้าง branch ทำให้ conflict เยอะตอนท้าย
ใช้ `git reset --hard` โดยยังไม่ได้ดูว่าไฟล์ไหนจะหาย
force push branch ที่คนอื่นใช้อยู่โดยไม่บอกทีม
เปิด PR ใหญ่เกินไป แก้หลายเรื่องใน PR เดียวจน review ยาก
คิดว่า repo private ปลอดภัยพอที่จะเก็บ secret ทั้งที่ key อาจหลุดจาก log, screenshot, token หรือคนในทีมได้
ไม่อ่าน diff ก่อน merge เพราะคิดว่า AI หรือ tool แก้ให้ถูกแล้ว
คำถามที่พบบ่อย
GitHub จำเป็นต้องใช้ command line ไหม?
ไม่จำเป็นเสมอไป คุณสามารถแก้ไฟล์ เปิด PR และ merge ผ่านเว็บ GitHub หรือ GitHub Desktop ได้ แต่ถ้าทำโปรเจกต์จริงหรือใช้ AI coding agent การเข้าใจคำสั่ง Git จะช่วยแก้ปัญหาได้เร็วและควบคุมงานได้ดีกว่า
ควร commit บ่อยแค่ไหน?
ควร commit เมื่อจบหนึ่งแนวคิดหรือหนึ่งชิ้นงานเล็ก ๆ เช่น เพิ่มบทความหนึ่งหน้า แก้บั๊ก login หนึ่งจุด หรือปรับ UI หนึ่ง section อย่ารอจนแก้ทุกอย่างเสร็จแล้วค่อย commit ก้อนใหญ่
ทำไม push แล้วขึ้น rejected?
มักเกิดเพราะ remote branch มี commit ใหม่ที่เครื่องคุณยังไม่มี ให้ดึงงานล่าสุดด้วย `git pull` หรือ `git pull --rebase` แก้ conflict ถ้ามี แล้วค่อย push ใหม่
ลบไฟล์หรือแก้ผิดแล้วกู้ได้ไหม?
ถ้ายังไม่ได้ commit อาจใช้ `git restore` กู้ไฟล์กลับจาก commit ล่าสุด ถ้า commit แล้วอาจใช้ `git revert` หรือ `git reset` ตามสถานการณ์ ถ้าหนักกว่านั้นให้ดู `git reflog` เพื่อหา commit เก่าที่เคยชี้อยู่
Pull Request ต้องใช้เฉพาะทีมใหญ่ไหม?
ไม่ใช่ คนทำคนเดียวก็ควรใช้ PR เมื่อโปรเจกต์เริ่มจริงจัง เพราะ PR เป็นจุดให้ตรวจ diff, เขียนสรุป, รัน checks และคุมการ merge เข้า main ได้สะอาดกว่า
ควรใช้ merge หรือ rebase?
มือใหม่ใช้ merge ก่อนเพราะตรงไปตรงมาและไม่ rewrite history ส่วน rebase เหมาะเมื่ออยากให้ history เป็นเส้นตรงหรือจัด commit ใน branch ส่วนตัว แต่ต้องระวังถ้า branch นั้นถูก push และคนอื่นใช้อยู่
อ่านต่อ / ไปต่อ
อ่านต่อ: ต่อ API ยังไงให้ปลอดภัย
คู่มือกันพลาดเรื่อง API key, secret, env, webhook และ rate limit สำหรับคนทำเว็บหรือ AI workflow
อ่านต่อ: รีวิว Replit สำหรับสร้างแอปด้วย AI
เหมาะกับคนที่อยากเริ่มเขียนเว็บ/แอป แล้วใช้ GitHub เก็บโค้ดและ deploy ต่อ
GitHub Docs: Hello World
เอกสารทางการสำหรับเข้าใจ repository, branch, commit และ pull request workflow
Git Reference: คำสั่ง Git ทั้งหมด
เอกสารทางการของ Git สำหรับค้นรายละเอียดคำสั่ง เช่น clone, commit, branch, rebase, revert และ reset
เช็กลิสต์ก่อนนำไปใช้
ทดลองกับงานจริงหนึ่งชิ้นก่อน เปรียบเทียบเวลาที่ประหยัด คุณภาพที่ได้ และค่าใช้จ่ายต่อเดือน แล้วค่อยขยายเป็น workflow ประจำทีม
Conversion path
ถ้าคู่มือนี้พาไปสู่โปรเจกต์จริง
ใช้คู่มือฟรีเพื่อวางโจทย์ก่อน จากนั้นเลือกทางที่เหมาะ: ซื้อ kit เมื่ออยากทำเว็บ/ระบบเอง หรือคุยบริการ LINE OA เมื่อมีธุรกิจที่ต้องตอบแชตลูกค้าจริง