IT General

Git Advanced Workflow

📅 2026-02-09 | โดย อ.บอม กิตติทัศน์ เจริญพนาสิทธิ์ — SiamCafe.net Since 1997

Git Advanced Workflow โดย อ.บอม SiamCafe.net

Git Advanced Workflow คืออะไร / ทำไมถึงสำคัญ

น้องๆ หลายคนคงคุ้นเคยกับการใช้ Git แบบพื้นฐาน commit -> push -> pull ใช่ไหม? แต่งานจริงมันซับซ้อนกว่านั้นเยอะ! Git Advanced Workflow คือการใช้ Git ให้มีประสิทธิภาพมากขึ้น เพื่อจัดการ project ขนาดใหญ่ที่มีคนทำงานร่วมกันหลายคน ป้องกันปัญหา code ตีกัน และทำให้การทำงานเป็นระบบระเบียบมากขึ้น

สมัยผมทำร้านเน็ต SiamCafe เนี่ย source code เล็กๆ แต่พอมีคนมาช่วยกันทำหลายคนนี่ปวดหัวเลยนะ ถ้าไม่มี workflow ที่ดี งานพังแน่นอน! ดังนั้นการเข้าใจ Git Advanced Workflow จึงสำคัญมากๆ สำหรับ developer ทุกคน

พื้นฐานที่ต้องรู้

Branching Model

Branch คือกิ่งก้านของ code หลักที่เราพัฒนา สมัยก่อนตอนหัดเขียนโปรแกรมใหม่ๆ ผมแก้ code บนไฟล์เดียวเลย (อย่าทำตามนะ!) พอมี Branch นี่ชีวิตดีขึ้นเยอะ เราสามารถสร้าง branch ใหม่เพื่อทดลอง feature ใหม่ๆ ได้โดยไม่กระทบ code หลัก

Merge vs. Rebase

Merge คือการรวม code จาก branch นึงเข้าอีก branch นึง โดยสร้าง commit ใหม่ขึ้นมา ส่วน Rebase คือการย้าย commit จาก branch นึงไปต่อท้ายอีก branch นึง เหมือนเราตัดกิ่งไม้ไปต่อกิ่งใหม่ เลือกใช้ให้ถูกสถานการณ์นะ

Conflict Resolution

หลีกเลี่ยงไม่ได้หรอกครับที่ code มันจะตีกัน! Conflict resolution คือการแก้ปัญหาเมื่อ Git ไม่สามารถ merge หรือ rebase ได้อัตโนมัติ เราต้องเข้าไปแก้ code เองแล้วบอก Git ว่าจะเอายังไง SiamCafe Blog มีบทความเรื่องนี้อยู่ ลองไปอ่านดู

วิธีใช้งาน / เริ่มต้นยังไง

อย่าเพิ่งกลัว! Git Advanced Workflow ไม่ได้ยากอย่างที่คิด ค่อยๆ เรียนรู้ไปทีละขั้น เริ่มจากทำความเข้าใจ concept ก่อน แล้วค่อยลองทำตามตัวอย่าง

Gitflow Workflow

Gitflow เป็น workflow ที่นิยมใช้กันมาก มี branch หลักๆ คือ main (หรือ master) สำหรับ code ที่ deploy ได้ และ develop สำหรับ code ที่กำลังพัฒนา นอกจากนี้ยังมี branch ย่อยๆ สำหรับ feature, release และ hotfix


# สร้าง feature branch
git checkout -b feature/new-feature develop

# ทำงานๆๆๆ

# Commit code
git add .
git commit -m "Add new feature"

# Merge เข้า develop
git checkout develop
git merge feature/new-feature

# Push develop
git push origin develop

GitHub Flow

GitHub Flow เหมาะสำหรับ project ที่มีการ deploy บ่อยๆ มี branch หลักแค่ main และทุก feature จะถูกพัฒนาบน branch ใหม่ แล้ว merge เข้า main ผ่าน Pull Request


# สร้าง branch ใหม่
git checkout -b new-feature

# ทำงานๆๆๆ

# Commit code
git add .
git commit -m "Add new feature"

# Push branch
git push origin new-feature

# สร้าง Pull Request บน GitHub

ขั้นตอนปฏิบัติจริง

การสร้าง Pull Request (PR)

Pull Request คือการขอให้คนอื่น review code ของเราก่อนที่จะ merge เข้า branch หลัก เป็นขั้นตอนสำคัญในการ maintain code quality สมัยผมทำ SiamCafe ก็ให้เพื่อนช่วย review code กันตลอด

สร้าง branch ใหม่สำหรับ feature
Commit code พร้อม message ที่สื่อความหมาย
Push branch ขึ้น remote repository
สร้าง Pull Request บน GitHub/GitLab/Bitbucket
รอคน review และแก้ไขตาม feedback
เมื่อ review เสร็จแล้ว ให้ merge เข้า branch หลัก

การจัดการ Conflict

เมื่อเกิด conflict Git จะแจ้งเตือนเรา เราต้องเปิดไฟล์ที่มี conflict แล้วแก้ไข code ให้ถูกต้อง โดย Git จะใส่เครื่องหมาย <<<<<<<, ======= และ >>>>>>> เพื่อบอกว่าส่วนไหนที่ conflict


<<<<<<< HEAD
This is the code in your branch.
========
This is the code in the other branch.
>>>>>>> other-branch

หลังจากแก้ไขแล้ว ให้ลบเครื่องหมายพวกนั้นออก แล้ว commit

เปรียบเทียบกับทางเลือกอื่น

นอกจาก Git แล้ว ยังมี Version Control System (VCS) อื่นๆ อีก แต่ Git เป็นที่นิยมมากที่สุด เพราะฟรี open source และมี community ขนาดใหญ่

VCS	ข้อดี	ข้อเสีย
Git	ฟรี, Open Source, Distributed, Branching ดี	อาจจะซับซ้อนสำหรับมือใหม่
Subversion (SVN)	ใช้งานง่าย, Centralized	Branching ไม่ดีเท่า Git
Mercurial	คล้าย Git, ใช้งานง่ายกว่า Git	Community เล็กกว่า Git

เลือกใช้ VCS ที่เหมาะกับ project ของเรา แต่ถ้าไม่รู้จะเลือกอะไร Git คือตัวเลือกที่ดีที่สุด

SiamCafe Blog มีบทความเปรียบเทียบ Git กับ SVN ลองไปอ่านดูได้

Best Practices / เคล็ดลับจากประสบการณ์

เอาล่ะ มาถึงส่วนที่สำคัญที่สุดแล้ว นั่นก็คือ "ทำยังไงให้ชีวิตง่ายขึ้น" กับ Git Advanced Workflow พวกนี้ สมัยผมทำร้านเน็ตฯ บอกเลยว่าเรื่องพวกนี้สำคัญมาก เพราะโค้ดเราไม่ได้มีแค่คนเดียวเขียน ต้องทำงานเป็นทีม แล้วแต่ละคนก็มีสไตล์การเขียนโค้ดเป็นของตัวเองทั้งนั้น

ปัญหาที่เจอประจำคือ Conflict! แก้กันจนเบื่อ บางทีแก้เสร็จแล้วพังกว่าเดิมอีก! ดังนั้น Best Practices ที่ผมจะแชร์ต่อไปนี้ มาจากประสบการณ์จริงที่เจ็บมาเยอะครับ

3 เทคนิคที่ใช้ได้จริง

1. Commit Message ให้ดี มีชัยไปกว่าครึ่ง

อย่า Commit แบบ "แก้บั๊ก" หรือ "อัพเดท" คือมันห่วยมาก! Commit Message ที่ดีต้องบอกให้ชัดเจนว่า Commit นี้ทำอะไร แก้ไขอะไร ทำไมถึงแก้แบบนี้

ผมแนะนำให้ใช้ Convention เช่น Conventional Commits (ลอง Search ดูนะ) มันจะช่วยให้ Commit Message ของเราเป็นระเบียบ อ่านง่าย และที่สำคัญคือ Generate Change Log ได้ง่ายมากๆ


feat: Add user authentication using OAuth2
fix(security): Prevent XSS vulnerability in comment section
docs: Update API documentation for payment gateway

2. Pull Request (PR) is your friend

อย่า Merge โค้ดเข้า Branch หลัก (เช่น main หรือ develop) โดยตรง เด็ดขาด! ให้สร้าง Pull Request (PR) เสมอ PR คือโอกาสให้เพื่อนร่วมทีม Review โค้ดของเรา หา Bugs หรือข้อผิดพลาดก่อนที่จะไปสร้างปัญหาใน Production

สมัยผมทำร้านเน็ตฯ ใคร Merge โค้ดเข้า main โดยไม่ผ่าน PR นี่โดนด่าเละ! (แต่ก็มีแอบทำบ้างนะ ตอนดึกๆ รีบๆ อิอิ)

3. Branching Strategy is King

Branching Strategy คือแผนการจัดการ Branch ของเรา มีหลายแบบให้เลือก เช่น Gitflow, GitHub Flow, GitLab Flow แต่ละแบบก็มีข้อดีข้อเสียต่างกันไป เลือกให้เหมาะกับ Project ของเรา

ส่วนตัวผมชอบใช้ GitHub Flow เพราะมันง่าย ไม่ซับซ้อน เหมาะกับ Project ขนาดเล็กถึงกลาง แต่ถ้า Project ใหญ่ๆ มีหลาย Feature ที่ต้องพัฒนาพร้อมกัน Gitflow ก็อาจจะเหมาะกว่า ลองศึกษาดูแล้วเลือกที่เหมาะกับทีมเราครับ

ถ้าเป็น Project เล็กๆ Single developer ผมแนะนำให้ใช้ Feature Branch Workflow ง่ายสุด


# สร้าง Feature Branch จาก main
git checkout -b feature/new-feature

# ทำงาน... ทำงาน... ทำงาน...

# Commit changes
git add .
git commit -m "feat: Implement new feature"

# Push branch ไป remote
git push origin feature/new-feature

# สร้าง Pull Request บน GitHub/GitLab

FAQ คำถามที่พบบ่อย

Q: Conflict แก้ยังไงให้ไม่ปวดหัว?

A: ใช้ Tools ช่วย! สมัยนี้มี IDE หลายตัวที่ช่วยแก้ Conflict ได้ดีมากๆ เช่น VS Code, IntelliJ IDEA มันจะช่วยให้เราเห็นความแตกต่างของโค้ด และ Merge ได้ง่ายขึ้น

อีกอย่างที่สำคัญคือ Communicate! คุยกับเพื่อนร่วมทีมว่าใครกำลังแก้โค้ดส่วนไหนอยู่ จะได้ไม่แก้ทับกัน

Q: Rebase กับ Merge เลือกอะไรดี?

A: อันนี้แล้วแต่สถานการณ์ ถ้าอยากให้ History ของ Branch หลักสะอาดตา ไม่รก ก็ Rebase แต่ต้องระวัง เพราะมันจะเปลี่ยน History ของ Commit ทำให้ Commit ID เปลี่ยนไปด้วย ถ้าไม่ชัวร์ Merge ปลอดภัยกว่า

Q: Git GUI ดีกว่า Command Line ไหม?

A: แล้วแต่คนชอบ! Git GUI ใช้งานง่าย เหมาะกับคนที่ไม่ถนัด Command Line แต่ Command Line ก็มีข้อดีคือมันยืดหยุ่นกว่า ทำอะไรได้เยอะกว่า ผมแนะนำให้ลองใช้ทั้งสองแบบ แล้วเลือกที่เหมาะกับตัวเอง

ส่วนตัวผมใช้ Command Line เป็นหลัก เพราะมันเท่ดี! (ล้อเล่นนะ จริงๆ มันเร็วกว่าด้วย)

สรุป

Git Advanced Workflow อาจจะดูซับซ้อน แต่ถ้าเข้าใจหลักการแล้ว มันจะช่วยให้เราทำงานเป็นทีมได้อย่างมีประสิทธิภาพ ลดปัญหา Conflict และทำให้โค้ดของเรามีคุณภาพมากขึ้น

อย่ากลัวที่จะลองผิดลองถูก เรียนรู้จากความผิดพลาด และที่สำคัญคือ Communicate กับเพื่อนร่วมทีมเสมอ iCafeForex ก็ใช้ Git เหมือนกันนะเออ!

หวังว่าบทความนี้จะเป็นประโยชน์กับทุกคนนะครับ ถ้ามีคำถามอะไร ถามมาได้เลย ผมยินดีตอบเสมอ แวะไปอ่านบทความอื่นๆ ที่ SiamCafe Blog ได้นะ มีเรื่อง IT สนุกๆ อีกเยอะเลย!