📋 CONTRIBUTING.md — ปรับปรุงให้สอดคล้องสาขา Origin
บังคับใช้โดย: GitHub Branch Protection Rules + github-coding CI Pipeline อัปเดตล่าสุด: 14 กันยายน 2026 · เวอร์ชัน: 1.1 โปรเจกต์: ZyntroAI/fastapi-python-boilerplate · สาขาหลัก: Origin
🛡️ ภาพรวม — เหตุผลที่ต้องมีกฎเหล่านี้
เพื่อรักษาคุณภาพ, ความปลอดภัย และสามารถตรวจสอบย้อนกลับได้ GitHub บล็อกการพุชตรงไปยังสาขาที่ได้รับการปกป้อง ทุกการเปลี่ยนแปลงต้องผ่านขั้นตอน:
PR → ตรวจสอบ CI → รีวิวโดยบุคคล → ประตูควบรวม → ผสาน → เผยแพร่อัตโนมัติ
รับประกันได้ว่า:
- ✅ โค้ดได้รับการตรวจสอบ
- ✅ การทดสอบทั้งหมดผ่าน
- ✅ การสแกนความปลอดภัยไม่พบปัญหา
- ✅ ไม่มีใครข้ามขั้นตอนคุณภาพ
- ✅ ประวัติสะอาด ตรวจสอบได้
🔒 สาขาที่ได้รับการปกป้อง
สาขา ระดับการปกป้อง การเปลี่ยนแปลงที่อนุญาต Origin 🔒 เข้มงวด — สถานะหลัก/ผลิตภัณฑ์ ผ่าน PR เท่านั้น · ต้องมีการอนุมัติ 1 ครั้ง · CI ทั้งหมดต้องผ่าน develop 🔒 มาตรฐาน — สภาพแวดล้อมทดสอบ ผ่าน PR เท่านั้น · ต้องมีการอนุมัติ 1 ครั้ง · CI ทั้งหมดต้องผ่าน feature/* / fix/* ✅ ไม่จำกัด สร้างได้อย่างอิสระ เปิด PR ได้
❌ การพุชตรงไปยัง Origin หรือ develop จะถูกปฏิเสธโดยอัตโนมัติ
✅ รายการตรวจสอบ PR ที่สมบูรณ์
ก่อนที่ PR จะสามารถผสานได้ ต้องผ่านทุกข้อต่อไปนี้:
🤖 การตรวจสอบอัตโนมัติ (ต้องผ่านทั้งหมด)
🧠 github-coding Pre-Check — ตรวจสอบสแต็ก · จัดรูปแบบ · Lint · ทดสอบ · สแกนความปลอดภัย · CodeQL 🧹 การตรวจสอบรูปแบบโค้ด — รูปแบบและคุณภาพโค้ด 🧪 การทดสอบหน่วย — ชุดทดสอบทั้งหมดผ่าน 🛡️ การบังคับใช้นโยบายผสาน — มีการอนุมัติจากบุคคล + ไม่มีป้ายความปลอดภัยที่สำคัญ สาขาเป็นปัจจุบัน ตรงกับสาขาเป้าหมาย ( Origin )
👀 ข้อกำหนดจากบุคคล (ต้องได้รับการอนุมัติ)
ต้องมีการอนุมัติอย่างน้อย 1 ครั้ง จากผู้ร่วมพัฒนา การอนุมัติจากเจ้าของโค้ด (หากแก้ไขคอนฟิก/เอกสารสำคัญ) ไม่มีคำขอเปลี่ยนแปลง หรือการอนุมัติเดิมถูกยกเลิกและอนุมัติใหม่ ไม่มีป้าย critical / security ที่บล็อกการผสาน
📝 มาตรฐานคุณภาพ PR
ปฏิบัติตามชื่อแบบ Conventional Commits: feat: , fix: , docs: , refactor: , chore: ฯลฯ คำอธิบายชัดเจน อธิบายการเปลี่ยนแปลง เชื่อมโยงกับปัญหา: Closes #123 หากเป็น PR ร่าง ต้องทำเครื่องหมาย พร้อมรีวิว
🔄 ขั้นตอนการพัฒนาที่สมบูรณ์
plaintext
-
สร้างสาขา └─ feature/คำอธิบายสั้นๆ ✅ เริ่มจากสาขา: Origin
-
เปิดคำขอดึง (PR) ├─ ชื่ออัตโนมัติ: "feat: อธิบายการเปลี่ยนแปลง" ├─ คำอธิบายอัตโนมัติจาก github-coding └─ ทำเครื่องหมายร่างจนกว่าจะพร้อม
-
🤖 ทำงานตรวจสอบอัตโนมัติ ├─ 🧠 Pre-Check → จัดรูปแบบ, Lint, ทดสอบ, สแกน ├─ 🧹 ตรวจสอบรูปแบบ ├─ 🧪 การทดสอบหน่วย └─ 🛡️ ประตูผสาน → รอการอนุมัติ
-
👀 การตรวจสอบโดยบุคคล ├─ ขอแก้ไข → แก้ไข ↺ └─ ✅ ได้รับการอนุมัติ → ประตูผสานผ่าน
-
✅ เปิดใช้งานการผสาน ├─ การตรวจสอบทั้งหมดผ่าน ✅ ├─ ได้รับการอนุมัติ ✅ ├─ สาขาเป็นปัจจุบันกับ Origin ✅ └─ ไม่มีความขัดแย้ง
-
🚀 ผสาน → เผยแพร่อัตโนมัติ ├─ สาขาต้นทางถูกลบโดยอัตโนมัติ ├─ เวอร์ชันเพิ่มขึ้น (patch) ├─ อัปเดตบันทึกการเปลี่ยนแปลง └─ สร้างรีลีสใหม่
⛔ สาเหตุที่ผสานไม่ได้ & วิธีแก้ไข
สาเหตุที่ถูกบล็อก สาเหตุที่เป็นไปได้ วิธีแก้ไข CI ไม่ผ่าน ข้อผิดพลาดรูปแบบ / ทดสอบล้ม / สแกนเจอปัญหา แก้ไขในเครื่อง, พุช — ระบบจะรันใหม่ รอการตรวจสอบ ยังไม่มีการอนุมัติ ขอตรวจสอบ; รอการอนุมัติ การอนุมัติล้าสมัย มีการพุชโค้ดเพิ่มหลังจากอนุมัติ อนุมัติอัตโนมัติหรือขอตรวจสอบใหม่ สาขาไม่เป็นปัจจุบัน สาขาเป้าหมาย Origin มีคอมมิตใหม่ อัปเดตสาขา: git pull Origin && git rebase Origin ป้ายความปลอดภัย มีป้าย: critical / security แก้ไขปัญหา → ลบป้ายออก ต้องตรวจสอบจากเจ้าของโค้ด แก้ไขไฟล์สำคัญ ขอตรวจสอบจากเจ้าของโค้ด
🧠 github-coding Pre-Check — ทำงานอย่างไร
PR จะรันชุดตรวจสอบคุณภาพทั้งหมดโดยอัตโนมัติ:
plaintext
🔍 ตรวจจับสแต็ก → Python/Node/Docker? ↓ ✅ จัดรูปแบบโค้ด → แก้ไขรูปแบบอัตโนมัติ ↓ ✅ ตรวจสอบรูปแบบ → ตรวจสอบคุณภาพ ↓ 🧪 รันการทดสอบ → ตรวจสอบว่าไม่มีอะไรเสียหาย ↓ 🔒 สแกนข้อมูลลับ → ไม่มีข้อมูลรับรองถูกคอมมิต ↓ 🔒 สแกน CodeQL → วิเคราะห์ความปลอดภัย ↓ 📝 อัปเดต PR → คำอธิบายสร้างเอง ↓ ✅ พร้อมรีวิว
💡 การแก้ไขรูปแบบจะถูกคอมมิตอัตโนมัติ ตรวจสอบ PR ของคุณหลังจากเปิด — github-coding อาจแก้ไขรูปแบบให้แล้ว!
📌 รูปแบบการตั้งชื่อสาขา
plaintext
feature/คำอธิบาย → ฟีเจอร์ใหม่ fix/หมายเลขปัญหา → แก้ไขข้อผิดพลาด refactor/สิ่งที่เปลี่ยน → ปรับปรุงโค้ด docs/สิ่งที่อัปเดต → อัปเดตเอกสาร chore/คำอธิบาย → บำรุงรักษา, CI, คอนฟิก release/vX.Y.Z → เตรียมรีลีส
🤝 วิธีทำให้ PR ผสานได้เร็วขึ้น
1. รักษา PR ให้เล็ก — ไม่เกิน 500 บรรทัด → ตรวจสอบเร็วขึ้น 2. PR ร่าง = กำลังทำ — ทำเครื่องหมายพร้อมเมื่อ CI ผ่าน 3. ชื่อและคำอธิบายชัดเจน — ปฏิบัติตาม Conventional Commits 4. เชื่อมโยงปัญหา — Closes #123 5. รอ CI ผ่าน✅ ก่อนขอตรวจสอบ 6. ตอบรับความคิดเห็น — พุชแก้ไข; ขอตรวจสอบใหม่ 7. ปุ่มผสานปรากฏขึ้น → เมื่อตรงตามทุกข้อกำหนด ✅
⚙️ การตั้งค่าอ้างอิง (สำหรับผู้ดูแลระบบ)
ผู้ดูแลระบบเท่านั้น: Settings → Branches → Branch protection rules
plaintext
Rule: Origin ✅ ต้องการ PR ก่อนผสาน ✅ ต้องการการอนุมัติ 1 ครั้ง ✅ ยกเลิกการอนุมัติที่ล้าสมัย ✅ ต้องการตรวจสอบจากเจ้าของโค้ด ✅ ต้องการตรวจสอบสถานะ: github-coding-precheck ✅ lint ✅ test ✅ merge-gate ✅ ✅ ต้องการให้สาขาเป็นปัจจุบัน ✅ บล็อกการพุชแบบ Force ✅ ลบสาขาต้นทางเมื่อผสาน ❌ อนุญาตให้ผู้ดูแลระบบข้าม → ปิด
Rule: develop
✅ ตรวจสอบเหมือนกัน, การอนุมัติเหมือนกัน
❓ คำถามที่พบบ่อย
Q: มีใครข้ามกฎเหล่านี้ได้ไหม?
ไม่มี — กฎใช้กับทุกคน รวมถึงผู้ดูแลระบบ มีเพียง Dependabot ที่สามารถผสานอัตโนมัติสำหรับการอัปเดต minor/patch เมื่อ CI ผ่านและได้รับการอนุมัติ
Q: หากต้องการผสานเร่งด่วนต้องทำอย่างไร?
ยังคงต้องการการอนุมัติ 1 ครั้ง เปิด PR → ผ่าน CI → ขอตรวจสอบ → อนุมัติ → ผสาน ใช้เวลาประมาณ 5 นาที
Q: ทำไม "ประตูผสาน" เป็นการตรวจสอบที่จำเป็น?
เป็นตัวยืนยันว่ามีมนุษย์อนุมัติแล้ว นี่คือ ประตูป้องกันการกระทำที่มีผลกระทบสูง — ระบบอัตโนมัติเสนอแนะ แต่มนุษย์ตัดสินใจ
Q: ผสาน PR ของตัวเองได้ไหม?
ได้ — แต่ยังคงต้องการ การอนุมัติจากคนอื่น 1 ครั้ง (หรืออนุมัติเองหากมีสิทธิ์เพียงพอ)
กฎเหล่านี้มีไว้เพื่อปกป้องสาขา Origin และผลิตภัณฑ์ ไม่ใช่เพื่อทำให้ช้าลง ทุกการตรวจสอบอัตโนมัติช่วยพบปัญหาก่อนลุกลาม ทุกการตรวจสอบโดยบุคคลช่วยแบ่งปันความรู้ ทุกประตูช่วยรักษาความปลอดภัย 🛡️
✅ บันทึกเป็นไฟล์:
plaintext
CONTRIBUTING.md
ต้องการให้ฉันสร้าง เทมเพลตคำขอดึง (PR Template) ที่รวมรายการตรวจสอบนี้ไว้ในทุก PR โดยตรงไหมครับ? 📋