PR Workflow & commit hygiene

หัวข้อนี้รวมทุกอย่างเป็น "วิธีทำงานจริง" ที่เกือบทุกทีมใช้ — แตก branch ทำฟีเจอร์, เปิด Pull Request ให้คนรีวิว, แล้วค่อย merge เข้า main พร้อมหลักการเขียน commit ที่ดี

Feature Branch Workflow

วงจรมาตรฐานของการเพิ่มฟีเจอร์หนึ่งอย่าง:

git switch main && git pull       # 1. อัปเดต main ล่าสุด
git switch -c feature-search      # 2. แตก branch ต่อฟีเจอร์
# 3. ...แก้โค้ด, commit เป็นช่วง ๆ...
git push -u origin feature-search # 4. push branch ขึ้น remote
# 5. เปิด Pull Request บน GitHub ให้คนรีวิว
# 6. รีวิวผ่าน -> merge เข้า main -> ลบ branch

Pull Request (PR) & Code Review

PR คือคำขอ "ขอรวม branch ของฉันเข้า main" บน GitHub เพื่อนร่วมทีมจะรีวิวโค้ด คอมเมนต์ ขอแก้ แล้วค่อยอนุมัติ — เป็นด่านคุณภาพก่อนเข้า main และเป็นที่ที่ทีมเรียนรู้จากกัน

• PR เล็ก รีวิวง่ายกว่า PR ใหญ่ — แยกเป็นเรื่อง ๆ
• เขียนคำอธิบาย PR ว่าแก้อะไร ทำไม ทดสอบยังไง
• ตอบ/แก้ตามคอมเมนต์รีวิวอย่างสุภาพ — รีวิวเรื่องโค้ด ไม่ใช่เรื่องคน
• CI (เทสต์อัตโนมัติ) ควรผ่านก่อน merge (เจอในบท Capstone)

commit message ที่ดี

commit message อธิบายว่า "ทำไม" ไม่ใช่แค่ "อะไร" หลายทีมใช้รูปแบบ conventional commits

# ❌ ไม่ดี
fix
update
งานวันนี้

# ✅ ดี (conventional commits: ประเภท: สรุป)
feat: add user search by email
fix: handle empty cart in checkout
docs: update README install steps
refactor: extract validation into helper

.gitignore & revert vs reset

# .gitignore — ไฟล์/โฟลเดอร์ที่ไม่เอาเข้า git
.venv/
__pycache__/
.env
*.log
node_modules/

git revert <commit>   # สร้าง commit ใหม่ที่ย้อนผลของ commit เดิม (ปลอดภัย ใช้กับของที่ push แล้ว)
git reset --hard <commit>  # ย้อนกลับไปจุดนั้น (อันตราย ลบประวัติหลังจุดนั้น)

สรุปหัวข้อนี้

• วงจร: อัปเดต main → แตก feature branch → push → เปิด PR → review → merge
• PR เป็นด่านรีวิวคุณภาพ — ทำเล็ก เขียนอธิบาย รีวิวเรื่องโค้ด
• commit message สื่อ "ทำไม" (conventional commits) + commit เล็กทีละเรื่อง
• .gitignore กันไฟล์ไม่พึงประสงค์; revert ปลอดภัยกว่า reset --hard