GitHub สำหรับงานจริง: วาง Workflow ให้ทีมทำงานต่อกันได้โดยไม่พัง

หลายทีมเริ่มใช้ GitHub จากจุดเล็ก ๆ แค่เก็บโค้ด สำรองไฟล์ และเปิด Pull Request เวลาจะแก้งาน แต่เมื่อระบบเริ่มโตขึ้น คนเริ่มมากขึ้น และมีหลายงานวิ่งพร้อมกัน ปัญหาจะเริ่มโผล่มาแบบชัดเจน เช่น

แก้คนละเรื่องแต่ชนกันทั้งไฟล์
merge แล้ว production พัง
PR ใหญ่มากจน review ไม่ไหว
ไม่มีใครรู้ว่าโค้ดชุดไหนถูก deploy ไปแล้ว
hotfix เข้า branch ไหนก่อนก็เถียงกันเอง
feature ค้างครึ่งทางแล้ว main branch เริ่มไม่น่าไว้ใจ

ปัญหาเหล่านี้มักไม่ได้เกิดจาก GitHub ใช้ยาก แต่เกิดจากทีมยังไม่มี workflow ที่ชัดเจนพอ ว่าใครควรทำอะไร เมื่อไร ผ่านขั้นตอนไหน และโค้ดจะเดินจากเครื่องนักพัฒนาไปจนถึง production อย่างไร

บทความนี้จะอธิบาย GitHub สำหรับงานจริงแบบเป็นระบบ โดยเน้นเรื่องที่ทีมเอาไปใช้ต่อได้ทันที ไม่ใช่แค่คำสั่งพื้นฐาน แต่เป็นการออกแบบ flow การทำงานให้ลดความเสี่ยงตั้งแต่ต้นทาง

GitHub ไม่ได้เป็นแค่ที่เก็บโค้ด

ถ้ามอง GitHub เป็นแค่ remote repository ทีมจะพลาดประโยชน์สำคัญไปมาก เพราะในงานจริง GitHub เป็นทั้ง

แหล่งอ้างอิงความจริงของ source code
พื้นที่พูดคุยเชิงเทคนิคผ่าน pull request
จุดควบคุมคุณภาพก่อน merge
ประวัติการเปลี่ยนแปลงที่ย้อนตรวจได้
จุดเชื่อมกับ CI/CD, issue tracking, release note และ deployment

ดังนั้นการออกแบบ workflow บน GitHub จึงไม่ใช่เรื่องของ "สะดวกหรือไม่สะดวก" อย่างเดียว แต่เป็นเรื่องของ

ความน่าเชื่อถือของระบบ
ความเร็วในการพัฒนา
ความชัดเจนในการรับผิดชอบ
ความสามารถในการตรวจสอบย้อนหลัง

ถ้าวางดี ทีมจะส่งงานได้เร็วขึ้นพร้อมความเสี่ยงที่ต่ำลง ถ้าวางไม่ดี GitHub จะกลายเป็นที่รวม chaos แบบที่ทุกคนกลัว merge กันไปวัน ๆ

เป้าหมายของ GitHub Workflow ที่ดี

ก่อนเลือกว่าจะใช้ branching model แบบไหน ควรถามก่อนว่า workflow ที่ดีต้องช่วยอะไรทีมบ้าง

1. main ต้องเชื่อถือได้

branch หลักควรอยู่ในสถานะที่พร้อม deploy หรืออย่างน้อยต้อง build ผ่านและไม่พังในระดับพื้นฐาน ถ้า main พังบ่อย ความมั่นใจทั้งทีมจะหายทันที

2. งานแต่ละชิ้นต้องแยกขอบเขตชัด

หนึ่ง branch ควรแทนหนึ่งเรื่องหลัก เช่น fix bug เดียว, เพิ่ม endpoint เดียว, ปรับหน้าเดียว หรือ refactor ชัดเจนหนึ่งกลุ่ม ไม่ควรจับหลายเรื่องมาปนกัน

3. review ต้องทำได้จริง

PR ที่ดีไม่ควรใหญ่จน reviewer เปิดมาแล้วปิดหนี การ review ที่มีคุณภาพเกิดจากขนาดที่เหมาะสม คำอธิบายชัด และเป้าหมายไม่ปนหลายเรื่อง

4. ย้อนตรวจได้ว่าอะไรเข้าเมื่อไร

ทีมควรรู้ว่าโค้ดชุดไหนเข้า main, ใคร approve, ตอนนั้น pipeline ผ่านไหม, และ release ไหนมี change อะไรบ้าง

5. hotfix ต้องมีทางเดินที่ชัด

เวลาระบบ production มีปัญหา ทีมไม่ควรเริ่มประชุมกันก่อนว่าจะ commit เข้าไหน ต้องมี flow เตรียมไว้แล้ว

โครงสร้าง branch ที่แนะนำสำหรับทีมส่วนใหญ่

หลายทีมชอบเริ่มจาก branching model ที่ซับซ้อนเกินความจำเป็น เช่นมีทั้ง main, develop, staging, release, qa, uat, hotfix/* หลายชั้นมาก แต่สุดท้ายไม่มีใครจำ flow ได้จริง

สำหรับทีมขนาดเล็กถึงกลาง แนวทางที่มักใช้งานได้ดีคือแบบนี้

main
feature/<short-name>
fix/<short-name>
chore/<short-name>
hotfix/<short-name>

แนวคิดคือ

main คือ branch หลักที่ต้องเชื่อถือได้
งานใหม่แตกออกเป็น feature/...
งานแก้ bug ที่ยังไม่วิกฤตใช้ fix/...
งานดูแลระบบ เช่น config, dependency, CI ใช้ chore/...
งานฉุกเฉิน production ใช้ hotfix/...

ตัวอย่างชื่อ branch

feature/user-profile-edit
fix/payment-status-mapping
chore/update-node-version
hotfix/login-session-expiry

ข้อดีของรูปแบบนี้คืออ่านง่าย ดูแล้วรู้เจตนา และทำให้ commit history กับ PR list มีความหมายมากขึ้น

ควรใช้ develop branch หรือไม่

คำตอบคือ ไม่จำเป็นเสมอไป

หลายทีมใช้ develop เพราะเคยเห็น flow นี้ใน Git Flow แบบดั้งเดิม แต่ในงานจริง modern CI/CD จำนวนมากสามารถทำงานได้ดีด้วย trunk-based หรือ main-based workflow ที่เรียบกว่า

ใช้ `main` เป็นศูนย์กลาง เหมาะเมื่อ

ทีมเล็กถึงกลาง
deploy บ่อย
มี CI ชัดเจน
feature แยกเป็น PR เล็กได้
มี feature flag หรือปล่อยงานแบบค่อย ๆ เปิดได้

ใช้ `develop` เพิ่มได้ เมื่อ

ทีมมี release cycle เป็นรอบใหญ่
ต้องรวมหลาย feature ก่อนขึ้น staging
มี QA/UAT แยกชัดก่อน production
โครงสร้างองค์กรยังต้องมี branch กลางสำหรับ integration

แต่แม้จะมี develop ก็ต้องระวังไม่ให้กลายเป็น branch ที่สะสมของค้างเยอะเกินไป เพราะ branch ยิ่งมีอายุยาว ความเสี่ยง conflict และ integration problem จะยิ่งสูง

ขั้นตอนทำงานที่แนะนำต่อหนึ่งงาน

นี่คือ flow ที่ทีมส่วนใหญ่เอาไปใช้ได้จริง

1. ดึง main ล่าสุดก่อนเริ่มงาน

git checkout main
git pull origin main

2. แตก branch ใหม่จาก main

git checkout -b feature/add-order-history-api

3. ทำงานเป็น commit ย่อยที่มีความหมาย

ไม่ควรรอรวบทุกอย่างแล้ว commit ครั้งเดียว ควรแบ่งตาม logic ที่อ่านย้อนหลังแล้วเข้าใจ เช่น

git add .
git commit -m "add order history query"
git commit -m "validate order history response schema"
git commit -m "add tests for empty order history state"

4. push branch ขึ้น GitHub

git push -u origin feature/add-order-history-api

5. เปิด Pull Request พร้อมอธิบายให้ชัด

PR ที่ดีควรมีอย่างน้อย

เป้าหมายของงาน
สิ่งที่เปลี่ยน
สิ่งที่ไม่ได้ทำใน PR นี้
วิธีทดสอบ
ผลกระทบที่อาจเกิดขึ้น
รูปภาพหรือ screenshot ถ้าเป็นงาน frontend

ตัวอย่างโครง PR description

## Summary
เพิ่ม API สำหรับดึงประวัติคำสั่งซื้อของผู้ใช้ที่ล็อกอินอยู่

## Changes
- เพิ่ม endpoint GET /orders/history
- เพิ่ม response schema
- เพิ่ม service query สำหรับดึงข้อมูลย้อนหลัง
- เพิ่ม unit tests

## Not Included
- pagination
- export CSV

## How to Test
1. login ด้วย user ปกติ
2. เรียก GET /orders/history
3. ตรวจสอบว่า response คืนเฉพาะ order ของ user นั้น

## Risks
- query อาจช้า หาก user มี order จำนวนมาก

6. ให้ CI รันก่อน review

ขั้นต่ำควรมี

install dependencies
lint
type check
unit test
build

7. review และแก้ตาม feedback

8. merge ด้วย policy ที่ทีมกำหนด

9. ลบ branch หลัง merge

การลบ branch หลัง merge ช่วยให้ repository สะอาด และลด branch ที่หมดอายุแต่ยังค้างอยู่

Pull Request ที่ดีควรเล็กแค่ไหน

ไม่มีตัวเลขตายตัว แต่หลักคิดคือ reviewer ควรอ่านแล้วเข้าใจภาพรวมได้ในรอบเดียว ถ้า PR หนึ่งมีทั้ง

เปลี่ยน database schema
เพิ่ม API ใหม่
refactor service เดิม
เปลี่ยนหน้า UI
แก้ test infra

ทั้งหมดใน PR เดียว มักใหญ่เกินไป

แนวทางลดขนาด PR

แยก preparation PR ก่อน เช่น rename, move file, cleanup
แยก schema change ออกจาก feature logic ถ้าทำได้
แยก backend กับ frontend ถ้าไม่ได้จำเป็นต้อง review พร้อมกัน
ใช้ draft PR ตั้งแต่ต้นเพื่อเปิด context ไว้ก่อน

PR ที่เล็กและชัดจะได้ประโยชน์สองชั้น

review ง่ายและเร็วขึ้น
เวลาย้อนดูประวัติในอนาคตก็เข้าใจง่ายขึ้นมาก

การเขียน commit message ให้มีประโยชน์จริง

commit message ที่ดีควรช่วยให้คนอ่านย้อนหลังเข้าใจว่าเปลี่ยนอะไร ไม่ใช่แค่พิมพ์กันลืม

ตัวอย่างที่ไม่ดี

git commit -m "fix"
git commit -m "update"
git commit -m "done"

ตัวอย่างที่ดี

git commit -m "fix null check in payment webhook parser"
git commit -m "add retry guard for invoice sync job"
git commit -m "refactor auth middleware to use shared token extractor"

ถ้าทีมต้องการมาตรฐานเพิ่ม อาจใช้ Conventional Commits เช่น

feat: add order history endpoint
fix: prevent duplicate payment callback processing
refactor: split pricing validator into reusable module
test: add coverage for expired session flow
chore: upgrade node to 22

ข้อดีคืออ่านง่าย และต่อยอดกับ release automation ได้

Merge แบบไหนดี: merge commit, squash, หรือ rebase

แต่ละแบบมีผลต่อความอ่านง่ายของ history

1. Merge Commit

เก็บประวัติครบ เห็นว่า branch นี้ merge เข้ามาตอนไหน

เหมาะเมื่อ

ต้องการเห็น context ของ branch
ทีมคุ้นกับ commit history แบบเต็ม

2. Squash and Merge

รวม commit ทั้ง branch ให้เหลือ commit เดียวตอนเข้า main

เหมาะเมื่อ

branch มี commit ย่อยเยอะมาก
ทีมต้องการ main history ที่สะอาด
review อิงที่ PR มากกว่า commit ย่อย

3. Rebase and Merge

ทำให้ history ดูเป็นเส้นตรง

เหมาะเมื่อ

ทีมเข้าใจ rebase ดี
ต้องการ history ที่เรียบและสะอาด

สำหรับหลายทีม Squash and Merge มักใช้งานง่ายสุด เพราะ main จะอ่านง่าย แต่ต้องเขียนชื่อ PR ให้มีคุณภาพ เพราะมันจะกลายเป็น commit message บน main ด้วย

Branch Protection คือเส้นกันพังที่ควรเปิดใช้

ถ้า repository สำคัญ ควรตั้ง branch protection กับ main อย่างน้อยดังนี้

ห้าม push ตรงเข้า main
ต้องเปิด PR ก่อน merge
ต้องมี approval อย่างน้อย 1 คน
ต้องผ่าน status checks ก่อน merge
block การ merge หาก branch out-of-date กับ main
จำกัดว่าใคร dismiss review ได้

ภาพรวมคือทำให้ main ไม่ถูกเปลี่ยนโดยไม่มีการตรวจสอบ

ตัวอย่าง policy ที่สมดุลสำหรับทีมทั่วไป

Require pull request before merging
Require 1 approval
Require status checks to pass
Require branches to be up to date before merging
Restrict direct pushes

ถ้าระบบมีความสำคัญสูง อาจเพิ่ม CODEOWNERS เพื่อบังคับ reviewer ตามพื้นที่รับผิดชอบ

ใช้ CODEOWNERS ให้ review เป็นระบบมากขึ้น

ไฟล์ CODEOWNERS ช่วยบอกว่าโฟลเดอร์หรือไฟล์ชุดไหนควรให้ใคร review เป็น default

ตัวอย่าง

* @team-leads
/frontend/ @frontend-team
/backend/ @backend-team
/docs/ @product-team @tech-writers
/.github/ @platform-team

ข้อดีคือ

ไม่ต้องคอยเดาเองว่าใครควร review
ลด PR ที่ไปค้างผิดคน
สะท้อน ownership ของระบบชัดขึ้น

แต่ต้องระวังไม่ตั้ง owner แคบเกินไปจนกลายเป็นคอขวด เพราะถ้ามีคนเดียวที่ approve ได้ ทุก PR จะรอคนนั้นหมด

Draft Pull Request มีประโยชน์กว่าที่คิด

หลายคนเปิด PR ตอนงานเสร็จแล้วเท่านั้น แต่ draft PR ช่วยได้มากในงานจริง โดยเฉพาะเมื่อ

งานใช้เวลาหลายวัน
ต้องการ feedback เรื่องแนวทางก่อนทำต่อ
อยากให้ทีมเห็น context ตั้งแต่ต้น
อยากให้ CI รันเร็ว ๆ เพื่อจับปัญหา integration

Draft PR ช่วยเปลี่ยน PR จาก "ด่านสุดท้ายก่อน merge" ให้กลายเป็น "พื้นที่สื่อสารระหว่างทำงาน" ซึ่งลดการหลงทางได้มาก

รีวิวโค้ดควรดูอะไรบ้าง

review ที่ดีไม่ใช่แค่ดูว่า syntax ผ่านหรือไม่ แต่ควรถามอย่างน้อย 5 เรื่องนี้

1. Correctness

โค้ดทำงานตรงตาม requirement ไหม มี edge case ที่หลุดไหม

2. Readability

คนอื่นมาอ่านต่อเข้าใจไหม ชื่อ function, variable, file structure สื่อความหมายไหม

3. Maintainability

มี duplication หรือ coupling ที่จะทำให้แก้ต่อยากไหม

4. Risk

เปลี่ยนส่วนนี้แล้วกระทบระบบอื่นไหม migration ปลอดภัยไหม backward compatible หรือเปล่า

5. Test Coverage

มี test ในระดับที่เหมาะไหม หรืออย่างน้อยมีวิธีพิสูจน์ว่าโค้ดนี้ไม่พังง่าย

ตัวอย่าง comment review ที่ดี

ฟังก์ชันนี้ครอบหลาย responsibility อยู่ทั้ง parse, validate และ persist
แนะนำแยก validate ออกมาเป็น helper เพื่อให้ test case ชัดขึ้นและลดผลกระทบตอนแก้ business rule รอบถัดไป

ตัวอย่าง comment ที่ไม่ค่อยช่วย

ไม่ค่อยโอเค

review ควรชัดว่ากังวลอะไร และถ้าเป็นไปได้ควรบอกเหตุผลหรือแนวทางแก้

อย่าปล่อยให้ CI เป็นแค่ของประดับ

หลายทีมมี GitHub Actions แต่ใช้แค่รัน test เบื้องต้น ทั้งที่จริง CI คือ gate สำคัญก่อนเข้า main

workflow ขั้นต่ำที่ควรมี

name: ci

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - name: Install
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Typecheck
        run: npm run typecheck

      - name: Test
        run: npm test -- --runInBand

      - name: Build
        run: npm run build

ถ้าทีมใช้ backend เพิ่มเติม อาจมี job แยกสำหรับ

Python tests
database migration checks
security scanning
container build validation

แนวคิดสำคัญคือ CI ต้องตอบคำถามให้ได้ว่า branch นี้พร้อม merge หรือยัง

เวลาต้อง sync main เข้ากับ branch งาน ควรทำอย่างไร

ถ้างานทำหลายวัน branch ของเรามักจะเก่ากว่า main วิธีที่ใช้มี 2 แบบ

merge main เข้า branch

git checkout feature/add-order-history-api
git fetch origin
git merge origin/main

ข้อดีคือปลอดภัย เข้าใจง่าย เหมาะกับคนส่วนใหญ่

rebase branch ไปบน main ล่าสุด

git checkout feature/add-order-history-api
git fetch origin
git rebase origin/main

ข้อดีคือ history สะอาด แต่ต้องระวังถ้า branch นี้แชร์กับคนอื่นแล้ว เพราะ rebase จะเปลี่ยน commit history

ถ้าทีมยังไม่ชำนาญ rebase มาก แนะนำใช้ merge main เข้า branch ก่อนก็เพียงพอ

วิธีจัดการ conflict แบบไม่ทำให้ทีมเสียเวลาเกินจำเป็น

merge conflict ไม่ใช่เรื่องแปลก แต่สิ่งที่ทำให้ทีมเหนื่อยคือ conflict ขนาดใหญ่ที่เกิดจาก branch อยู่ค้างนานเกินไป

ลด conflict ได้ด้วยวิธีนี้

ทำ PR ให้เล็กและ merge บ่อย
ดึง main ล่าสุดเสมอก่อนเริ่มงาน
อย่าค้าง branch หลายสัปดาห์โดยไม่ sync
แยก ownership ไฟล์ให้ชัด
ลดการแก้ formatting ทั้งไฟล์พร้อม logic change

ถ้า conflict เกิดขึ้น ให้ดูความหมายของโค้ดจริง อย่าแก้แค่ให้ merge ผ่าน เพราะหลายครั้ง conflict ที่ผ่านได้อาจซ่อน regression ไว้

หลังแก้ conflict ควรรัน test อีกครั้งเสมอ

Release และ Tag ควรใช้เมื่อไร

ถ้าระบบมีการปล่อยเวอร์ชันจริง ควรใช้ Git tag หรือ GitHub Release เพื่อบอกจุดสำคัญในประวัติ

ตัวอย่าง tag

git tag -a v1.4.0 -m "Release v1.4.0"
git push origin v1.4.0

ประโยชน์คือ

รู้ว่าโค้ดเวอร์ชันไหนถูกปล่อย
ใช้ rollback ได้ง่ายขึ้น
ทำ release note อัตโนมัติได้
ผูกกับ artifact หรือ deployment pipeline ได้

ถ้าทีม deploy จาก main ตลอด ก็ยังควรมีอย่างน้อย release point ที่อ้างอิงได้ในงานสำคัญ

Hotfix ควรมี flow ชัดเจนตั้งแต่ก่อนเกิดปัญหา

เวลาระบบ production พัง ทีมที่ไม่มี hotfix flow มักเริ่มจากความสับสน เช่น

แก้บน branch เดิมดีไหม
merge เข้า develop ก่อนหรือ main ก่อน
deploy ตรงจาก local ได้หรือเปล่า

flow ที่ปลอดภัยกว่า

แตก hotfix/... จาก main
แก้เฉพาะจุดที่จำเป็น
เปิด PR แบบเร่งด่วน
รัน checks ที่จำเป็น
review อย่างน้อยหนึ่งคน
merge เข้า main
deploy
ถ้ามี branch กลางอย่าง develop ให้ back-merge กลับด้วย

ตัวอย่าง

git checkout main
git pull origin main
git checkout -b hotfix/fix-payment-callback-timeout

หลักสำคัญคือ hotfix ต้องแคบ ชัด และไม่แอบรวม refactor ที่ไม่เกี่ยว

เรื่องที่ทีมพลาดบ่อยบน GitHub

1. เปิด PR ใหญ่มาก

ผลคือ review ไม่ละเอียด, merge ช้า, ความเสี่ยงสูง

2. merge โดยไม่มี context

ชื่อ PR ไม่ชัด ไม่มี description ไม่มีวิธีทดสอบ คนอนุมัติจึงดูแค่คร่าว ๆ

3. ไม่มี branch protection

ใครก็ push เข้า main ได้ ทำให้ระบบเปราะมาก

4. ปล่อย branch ค้างนานเกินไป

สุดท้าย conflict หนักและ requirement เปลี่ยนไปแล้ว

5. ใช้ GitHub แค่เก็บโค้ด แต่ไม่ใช้ issue, labels, milestone, release

ทำให้ trace งานยาก และภาพรวมของโครงการไม่ชัด

6. commit message ไม่สื่อความหมาย

พอย้อนดูว่า bug นี้เข้ามาตอนไหนกลับหาไม่เจอ

7. review เน้น style มากกว่า design หรือ correctness

เรื่อง format ให้ formatter จัดการ review ควรใช้พลังกับ logic, risk และ architecture มากกว่า

Workflow ตัวอย่างสำหรับทีมทั่วไป

นี่คือตัวอย่าง workflow ที่เรียบแต่ใช้งานได้จริง

กติกา

main ต้อง build ผ่านเสมอ
ห้าม push ตรงเข้า main
ทุกงานต้องผ่าน PR
PR ต้องมี Summary, Changes, How to Test
ต้องผ่าน lint, test, build
ต้องมี approval อย่างน้อย 1 คน
ใช้ squash merge
ลบ branch หลัง merge

flow ประจำวัน

เลือก issue
แตก branch จาก main
ทำงานเป็น commit ย่อย
เปิด draft PR เร็ว
ให้ CI รัน
ขอ review เมื่อพร้อม
แก้ feedback
merge เมื่อ checks ผ่าน
deploy ตาม pipeline

workflow แบบนี้ไม่ได้หรูหรือซับซ้อน แต่เพียงพอให้ทีมส่วนใหญ่ทำงานอย่างมีวินัยและตรวจสอบย้อนหลังได้ดีมาก

ตัวอย่างไฟล์ Pull Request Template

ถ้าอยากให้ PR สม่ำเสมอ ควรเพิ่ม template ไว้ใน repository

ไฟล์: .github/pull_request_template.md

## Summary

## Changes
- 
- 
- 

## How to Test
1. 
2. 
3. 

## Screenshots / Evidence

## Risks / Notes

ประโยชน์คือช่วยบังคับคุณภาพขั้นต่ำของการสื่อสารใน PR โดยไม่ต้องคอยเตือนกันทุกครั้ง

ตัวอย่าง GitHub Actions สำหรับ block merge ถ้า test ไม่ผ่าน

name: pull-request-checks

on:
  pull_request:
    branches:
      - main

jobs:
  verify:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test
      - run: npm run build

เมื่อตั้ง branch protection ให้ require check นี้ก่อน merge ทีมจะลดความผิดพลาดที่ไม่จำเป็นได้มาก

ถ้าทีมโตขึ้น ควรต่อยอดอะไรบน GitHub อีก

เมื่อ workflow พื้นฐานเริ่มนิ่งแล้ว ค่อยขยับไปเรื่องต่อไปนี้

1. Labels และ Issue Triage

ใช้ label แยกประเภทเช่น

bug
feature
infra
docs
security
high-priority

2. Milestone

ผูก issue กับ release หรือ sprint เพื่อเห็น progress เป็นภาพรวม

3. GitHub Projects

ใช้จัดงานในระดับ board โดยไม่ต้องพึ่งเครื่องมือเสริมเสมอไป

4. Release Notes

สรุปสิ่งที่เปลี่ยนในแต่ละ release ให้ทีมภายในและลูกค้าเข้าใจง่ายขึ้น

5. Security Features

เช่น Dependabot, secret scanning, code scanning ถ้าระบบเริ่มสำคัญขึ้น

สรุป

GitHub ที่ใช้งานได้ดีในทีม ไม่ได้ขึ้นอยู่กับว่ามีฟีเจอร์เยอะแค่ไหน แต่ขึ้นอยู่กับว่าทีมวางกติกาการทำงานได้ชัดแค่ไหน

แก่นของ workflow ที่ดีมีไม่กี่ข้อ

main ต้องเชื่อถือได้
งานต้องแยกขอบเขตชัด
PR ต้อง review ได้จริง
CI ต้องช่วยกันพัง
branch protection ต้องกันความเสี่ยง
release และ hotfix ต้องมีทางเดินที่ชัด

เมื่อทีมมี workflow ที่ดี GitHub จะไม่ใช่แค่ที่เก็บโค้ด แต่จะกลายเป็นระบบควบคุมคุณภาพและความเปลี่ยนแปลงของซอฟต์แวร์อย่างแท้จริง

และนี่คือจุดต่างสำคัญระหว่างทีมที่ "แค่ใช้ GitHub" กับทีมที่ "ใช้ GitHub เพื่อส่งงานอย่างมีวินัยและเชื่อถือได้"

GitHub สำหรับงานจริง: วาง Workflow ให้ทีมทำงานต่อกันได้โดยไม่พัง

GitHub ไม่ได้เป็นแค่ที่เก็บโค้ด

เป้าหมายของ GitHub Workflow ที่ดี

1. main ต้องเชื่อถือได้

2. งานแต่ละชิ้นต้องแยกขอบเขตชัด

3. review ต้องทำได้จริง

4. ย้อนตรวจได้ว่าอะไรเข้าเมื่อไร

5. hotfix ต้องมีทางเดินที่ชัด

โครงสร้าง branch ที่แนะนำสำหรับทีมส่วนใหญ่

ควรใช้ develop branch หรือไม่

ใช้ main เป็นศูนย์กลาง เหมาะเมื่อ

ใช้ develop เพิ่มได้ เมื่อ

ขั้นตอนทำงานที่แนะนำต่อหนึ่งงาน

1. ดึง main ล่าสุดก่อนเริ่มงาน

2. แตก branch ใหม่จาก main

3. ทำงานเป็น commit ย่อยที่มีความหมาย

4. push branch ขึ้น GitHub

5. เปิด Pull Request พร้อมอธิบายให้ชัด

6. ให้ CI รันก่อน review

7. review และแก้ตาม feedback

8. merge ด้วย policy ที่ทีมกำหนด

9. ลบ branch หลัง merge

Pull Request ที่ดีควรเล็กแค่ไหน

การเขียน commit message ให้มีประโยชน์จริง

Merge แบบไหนดี: merge commit, squash, หรือ rebase

1. Merge Commit

2. Squash and Merge

3. Rebase and Merge

Branch Protection คือเส้นกันพังที่ควรเปิดใช้

ใช้ CODEOWNERS ให้ review เป็นระบบมากขึ้น

Draft Pull Request มีประโยชน์กว่าที่คิด

รีวิวโค้ดควรดูอะไรบ้าง

1. Correctness

2. Readability

3. Maintainability

4. Risk

5. Test Coverage

อย่าปล่อยให้ CI เป็นแค่ของประดับ

เวลาต้อง sync main เข้ากับ branch งาน ควรทำอย่างไร

merge main เข้า branch

rebase branch ไปบน main ล่าสุด

วิธีจัดการ conflict แบบไม่ทำให้ทีมเสียเวลาเกินจำเป็น

Release และ Tag ควรใช้เมื่อไร

Hotfix ควรมี flow ชัดเจนตั้งแต่ก่อนเกิดปัญหา

เรื่องที่ทีมพลาดบ่อยบน GitHub

1. เปิด PR ใหญ่มาก

2. merge โดยไม่มี context

3. ไม่มี branch protection

4. ปล่อย branch ค้างนานเกินไป

5. ใช้ GitHub แค่เก็บโค้ด แต่ไม่ใช้ issue, labels, milestone, release

6. commit message ไม่สื่อความหมาย

7. review เน้น style มากกว่า design หรือ correctness

Workflow ตัวอย่างสำหรับทีมทั่วไป

กติกา

flow ประจำวัน

ตัวอย่างไฟล์ Pull Request Template

ตัวอย่าง GitHub Actions สำหรับ block merge ถ้า test ไม่ผ่าน

ถ้าทีมโตขึ้น ควรต่อยอดอะไรบน GitHub อีก

1. Labels และ Issue Triage

2. Milestone

3. GitHub Projects

4. Release Notes

5. Security Features

สรุป

ใช้ `main` เป็นศูนย์กลาง เหมาะเมื่อ

ใช้ `develop` เพิ่มได้ เมื่อ