GitHub 101 สำหรับคนเริ่มต้น อธิบายแบบใช้งานจริง

GitHub 101
แบบที่หญิงอ่านแล้วใช้งานได้จริง

เป้าของหน้านี้คือทำให้คำพวก clone, branch, commit, remote, issue, PR, code review, CI/Actions กลายเป็นเรื่องง่าย ไม่ใช่ศัพท์ลอย ๆ

ภาพใหญ่ คำศัพท์หลัก workflow จริง คำสั่งที่เจอบ่อย บนหน้าเว็บ GitHub เช็กความเข้าใจ

1) ภาพใหญ่ก่อน: Git กับ GitHub ต่างกันยังไง

Git

Git คือระบบเก็บประวัติการเปลี่ยนแปลงของไฟล์/โค้ด เช่น วันนี้แก้อะไร เมื่อวาน revert ได้ไหม ใครแก้บรรทัดนี้

GitHub

GitHub คือเว็บ/บริการที่เอา repo Git ไปเก็บไว้บนออนไลน์ แล้วเพิ่มของที่คนทำงานร่วมกันใช้ เช่น PR, Issue, Review, CI, Actions

คิดง่าย ๆ: Git = เครื่องมือเก็บประวัติ และ GitHub = ที่อยู่บนออนไลน์ + ที่คุย + ที่ปล่อยงานเป็นทีม

2) คำศัพท์หลักที่หญิงเจอบ่อย

repo
โฟลเดอร์โปรเจกต์ที่อยู่ใน Git เช่นเว็บ, bot, worker, app
clone
ดึง repo จาก GitHub ลงมาไว้ในเครื่องเรา
branch
เส้นงานย่อย เช่น main คือเส้นหลัก, feature/login คือเส้นงานที่กำลังทำ
commit
จุดบันทึกการเปลี่ยนแปลง 1 ชุด พร้อมข้อความอธิบายว่าแก้อะไร
remote
ที่อยู่ของ repo บนออนไลน์ เช่น GitHub ต้นทาง
push
ส่ง commit จากเครื่องเราไป GitHub
pull
ดึงของใหม่จาก GitHub ลงมา
issue
ตั๋วงาน/รายการปัญหา/feature request เช่น “แก้บั๊ก login”
PR (Pull Request)
คำขอรวมโค้ดจาก branch หนึ่งเข้าอีก branch หนึ่ง พร้อมให้คน review
review code
ดูว่าโค้ดโอเคไหม มี bug ไหม naming ดีไหม logic ปลอดภัยไหม
CI / Actions
งานอัตโนมัติ เช่น run test, lint, build ทุกครั้งที่ push หรือเปิด PR

3) ของที่เฮอบอกก่อนหน้านี้ หมายถึงอะไรแบบภาษาคน

clone repo ลงเครื่อง

คือเอาโปรเจกต์จาก GitHub มาวางใน Mac ของหญิง เพื่อเปิดไฟล์ แก้โค้ด รันโปรแกรม หรือดูเอกสารในเครื่องได้

git clone https://github.com/owner/repo.git

เปิด issue / PR

Issue คือ “มีงานอะไรต้องทำ” ส่วน PR คือ “งานทำเสร็จแล้ว ขอเอาเข้า main ได้ไหม”

review code

คืออ่าน diff แล้วเช็กว่าแก้ถูกจุดไหม มี side effect ไหม มีอะไรน่าปรับก่อน merge

ดู CI / Actions

คือดูว่าระบบอัตโนมัติผ่านไหม เช่น tests ผ่าน, build ผ่าน, deploy ผ่าน

เช็ก branch / commit / remote

ใช้ดูว่าเราอยู่เส้นงานไหน, บันทึกอะไรไปบ้าง, แล้ว repo นี้ชี้ไป GitHub ที่ไหน

4) workflow จริง แบบใช้งานทุกวัน

1

มีงานเกิดขึ้น

เช่น “เพิ่มปุ่มส่งใบเสร็จ” หรือ “แก้บั๊กยอดรวมผิด” งานนี้มักถูกบันทึกเป็น Issue

2

แยก branch ไปทำงาน

ไม่แก้บน main ตรง ๆ แต่แยก branch เช่น feature/receipt-button

3

แก้ไฟล์ในเครื่อง

เปิดโปรเจกต์ แก้โค้ด ทดสอบในเครื่อง

4

commit

บันทึกการเปลี่ยนแปลงเป็นช่วง ๆ พร้อมข้อความ เช่น feat: add receipt send button

5

push ขึ้น GitHub

เอา branch ที่เราทำขึ้นไปบน GitHub

6

เปิด PR

ขอ merge งานเข้ากับ main พร้อม description ว่าแก้อะไร มีผลอะไร ต้องเช็กอะไร

7

CI / Review ทำงาน

ระบบรัน test อัตโนมัติ และคน/AI มาช่วย review

8

merge

พอผ่าน review และ CI แล้ว ค่อย merge เข้าเส้นหลัก

สรุป workflow สั้นที่สุด: Issue → Branch → Code → Commit → Push → PR → Review/CI → Merge

5) ทำไมไม่แก้ตรงใน main เลย?

ข้อดีของ branch

  • งานแต่ละเรื่องไม่ปนกัน
  • ถ้าพัง ลบทิ้ง branch นั้นได้
  • review เป็นก้อนเข้าใจง่าย
  • หลายคนทำพร้อมกันได้

ถ้าแก้บน main ตรง ๆ

  • เสี่ยงทำของหลักพัง
  • แยกไม่ออกว่าแก้อะไรเมื่อไร
  • review ยาก
  • rollback ยุ่ง

6) คำสั่งที่เจอบ่อย พร้อมความหมาย

git clone https://github.com/owner/repo.git
# ดึง repo มาลงเครื่อง

git branch
# ดู branch ที่มี

git checkout -b feature/my-task
# สร้าง branch ใหม่แล้วสลับไป branch นั้น

git status
# ดูว่าไฟล์ไหนเปลี่ยนบ้าง

git add .
# เตรียมไฟล์ที่จะ commit

git commit -m "feat: add receipt send button"
# บันทึกการเปลี่ยนแปลงเป็น 1 จุด

git push origin feature/my-task
# ส่ง branch นี้ขึ้น GitHub

git pull
# ดึงของใหม่จาก GitHub

git remote -v
# ดูว่า repo นี้ชี้ไปที่ GitHub ไหน

git log --oneline --decorate -n 10
# ดู commit ล่าสุดแบบสั้น ๆ
คำเตือนที่เจอบ่อย: commit ยังไม่เท่ากับขึ้น GitHub นะ — commit อยู่ในเครื่อง, ต้อง push ถึงจะขึ้นออนไลน์

7) บนหน้าเว็บ GitHub มีอะไรบ้าง

Issues

เหมาะกับการเก็บงาน เช่น bug, feature, TODO, คำถาม, task สำหรับ AI/dev

  • Title = ชื่องาน
  • Description = รายละเอียด
  • Labels = ประเภท เช่น bug / feature
  • Assignee = ใครรับงาน

Pull Requests

เป็นที่คุยกันก่อน merge โค้ด เหมาะมากเวลาให้คนหรือ AI review

  • ดู diff ว่าเปลี่ยนบรรทัดไหน
  • comment รายบรรทัดได้
  • เห็นผล CI ได้
  • กด merge ได้เมื่อพร้อม

Actions / CI

หน้าที่บอกว่า automation ผ่านไหม เช่น lint, unit tests, build, deploy

Code tab

ดูไฟล์ทั้งหมด, branch selector, commit history, download zip, copy clone URL

8) PR กับ Issue ต่างกันแบบจำง่าย

Issue = งานที่ต้องทำ

ตัวอย่าง: “ยอดรายวันรวม VAT ผิด”

PR = วิธีแก้งานนั้น

ตัวอย่าง: “Fix VAT calculation in daily summary”

9) review code คือดูอะไร

  • แก้ตรง requirement ไหม
  • มี bug ซ่อนอยู่ไหม
  • โค้ดอ่านง่ายไหม
  • ตั้งชื่อตัวแปร/functions ดีไหม
  • มี side effect กับส่วนอื่นไหม
  • มี test ไหม ถ้าควรมี
  • security / permissions / secrets ปลอดภัยไหม

10) CI / Actions ทำไมสำคัญ

ถ้าไม่มี CI เวลามีคน push อาจจะไม่รู้เลยว่าโค้ดพังหรือ test fail แต่ถ้ามี CI ระบบจะเช็กให้ทันที

หญิงไม่จำเป็นต้องเขียน workflow เองทั้งหมดก่อน แค่รู้ว่า สีเขียว = ผ่าน, สีแดง = มีอะไรพัง ก็เริ่มใช้งานได้แล้ว

11) ตัวอย่างสถานการณ์จริง

กรณี 1: แค่ดูโค้ด

หญิงสั่งเฮอว่า “clone repo นี้มาแล้วดูว่ามีไฟล์ config ตรงไหน”

แปลว่าเฮอจะ clone repo ลงเครื่อง แล้วอ่านไฟล์ในเครื่อง

กรณี 2: ทำงานใหม่

หญิงสั่งว่า “เพิ่ม export PDF”

flow ที่ดีคือเปิด issue → แยก branch → เขียนโค้ด → เปิด PR

กรณี 3: อยากรู้ว่าพังตรงไหน

หญิงบอกว่า “PR นี้ CI fail”

เฮอจะไปดู Actions log ว่าพังเพราะ test, lint หรือ build

กรณี 4: อยากรู้ว่ากำลังต่อกับ repo ไหน

ใช้ git remote -v

จะบอกว่า origin ชี้ไป GitHub URL ไหน

12) เช็กความเข้าใจเร็ว ๆ

Q1: Commit กับ Push ต่างกันยังไง?

Commit = บันทึกในเครื่องเรา ส่วน Push = ส่งสิ่งที่ commit แล้วขึ้นไปบน GitHub

Q2: Issue กับ PR ต่างกันยังไง?

Issue = งาน/ปัญหาที่ต้องทำ, PR = คำขอรวมโค้ดที่ใช้แก้งานนั้น

Q3: ทำไมต้องใช้ branch?

เพื่อแยกงานออกจาก main, ลดความเสี่ยง, review ง่าย, rollback ง่าย และให้หลายคนทำพร้อมกันได้

Q4: CI fail หมายความว่าอะไร?

แปลว่าระบบอัตโนมัติบางอย่างไม่ผ่าน เช่น test fail, lint fail, build fail หรือ deploy fail

13) ถ้าหญิงอยากเริ่มใช้จริง ให้เริ่มแค่นี้ก่อน

A

รู้จัก 5 คำนี้ให้แม่น

repo / branch / commit / issue / PR

B

จำ workflow หนึ่งประโยค

มีงาน → ทำ branch → commit → push → เปิด PR

C

ให้เฮอช่วยทำทีละขั้น

เช่น “clone repo นี้มา”, “ดู PR นี้”, “เปิด issue นี้”, “อธิบาย CI fail อันนี้หน่อย”

หญิงไม่จำเป็นต้องจำคำสั่งทั้งหมดในวันเดียว ขอแค่เข้าใจ ภาพรวมของ flow ก่อน แล้วค่อยใช้งานจริงกับโปรเจกต์ของตัวเอง