git-parsec — จากการสร้าง worktree ไปจนถึงการ merge PR ด้วยตั๋วใบเดียว

เป็นเครื่องมือ CLI สำหรับทำงานอัตโนมัติกับเวิร์กโฟลว์การพัฒนาแบบขนานที่อิงกับ Git worktree

ปัญหาที่เครื่องมือนี้แก้ได้

เมื่อต้องทำงานหลายตั๋วพร้อมกันโดยไม่ต้องสลับบรাঞ্চ git worktree เป็นตัวเลือกที่ดี
แต่หากจะใช้ในงานจริง มักมีงานซ้ำ ๆ อยู่มาก:

• สร้าง worktree และตั้งชื่อบรাঞ্চ → เหลือแค่บรรทัดเดียว parsec start PROJ-123
• push, สร้าง PR, และแนบลิงก์ตั๋ว → เหลือแค่บรรทัดเดียว parsec ship PROJ-123
• ตรวจ CI, merge, และเก็บกวาด worktree → เหลือแค่บรรทัดเดียว parsec merge PROJ-123

งานที่ต้องทำซ้ำทุกครั้งถูกย่อให้เหลือคำสั่งบรรทัดเดียวในแต่ละขั้นตอน

เวิร์กโฟลว์หลัก

parsec start PROJ-123       # worktree + บรাঞ্চ + เชื่อมกับตั๋ว Jira  
# ... เขียนโค้ด ...  
parsec ship PROJ-123        # push → สร้าง PR (ใส่ชื่อตั๋ว/ลิงก์อัตโนมัติ)  
parsec ci PROJ-123          # แสดงตารางสถานะ CI  
parsec merge PROJ-123       # รอ CI → squash merge → ล้าง worktree อัตโนมัติ  

ฟีเจอร์หลัก

การเชื่อมต่อกับตัวติดตามงาน

• Jira / GitHub Issues — ดึงชื่อตั๋วอัตโนมัติ, เปลี่ยนสถานะ, มุมมองบอร์ด, อินบ็อกซ์
• parsec ticket — ดูรายละเอียดตั๋วจากในเทอร์มินัล
• parsec board — ดูบอร์ดสปรินต์ Jira ผ่าน CLI

การจัดการ worktree

• การรวมกับ Shell — ใช้ parsec switch เพื่อ cd ย้ายระหว่าง worktree อัตโนมัติ
• Stack PR — ใช้ออปชัน --on เพื่อจัดโซ่ PR และใช้ stack sync เพื่อ rebase แบบรวดเดียว
• Undo — กู้คืน worktree ที่เผลอลบทิ้งได้ในคำสั่งเดียว

ระบบอัตโนมัติ

• Release — สร้างแท็ก + merge + GitHub Release + changelog อัตโนมัติ
• โหมดแสดงผล Human / JSON / Quiet — เชื่อมต่อกับสคริปต์ CI ได้สะดวก
• 27 ซับคอมมานด์ — start, list, status, ship, merge, ci, diff, sync, adopt, rename เป็นต้น

การติดตั้ง

cargo install git-parsec  

หรือดาวน์โหลดไบนารีสำหรับ macOS / Linux ได้จาก GitHub Releases

เหมาะกับใคร

• คนที่ทำหลายตั๋วพร้อมกัน (การพัฒนาแบบขนานด้วย worktree)
• คนที่เบื่องานซ้ำ ๆ ระหว่าง Jira + Git
• คนที่อยากลดต้นทุนของการสลับบริบทใน monorepo
• คนที่อยากมอบสภาพแวดล้อมการทำงานแบบแยกอิสระให้ AI agent (เช่น Claude Code)

ลิงก์

• GitHub: https://github.com/erishforG/git-parsec
• ติดตั้ง: cargo install git-parsec

เขียนด้วย Rust จึงมีขนาดเบา และนำไปใช้กับ Git repository เดิมได้ทันที
ยินดีรับฟีดแบ็กหรือคำถาม!

[puddingman220]

ช่วงหลังผมได้อ่านบล็อกเทคเกี่ยวกับ parallel worktree แล้วรู้สึกสนใจ แต่ก็น่าเสียดายที่ไม่สามารถดูรายละเอียดการพัฒนาได้ ดังนั้นคงต้องลองเจาะลึกกับโอเพนซอร์สตัวนี้สักครั้งแล้วครับ!

ด้านล่างคือบทความบล็อกที่ผมอ่านมา
https://medium.com/ajd-tech/…

[erish2150]

ขอบคุณครับ! เนื้อหาที่เขียนในบล็อกก็เขียนออกมาได้ยอดเยี่ยมมาก แม้จะอ่านผ่าน ๆ ก็ยังรู้สึกได้เลย
ถ้ามีโอกาส ลองดูแล้วหากมีจุดที่ไม่ถูกใจหรืออยากปรับปรุงตรงไหน ก็สามารถเปิด issue หรือส่ง PR มาได้อย่างสบาย ๆ เลยครับ!

[shaun0927]

ผมมองว่า worktree แบบขนานคือแนวทางจาก work dirty -> clean nicely
และคิดว่านี่จะกลายเป็นรูปแบบการพัฒนาหลักในอนาคต
ดูเป็นเรโปที่ดีมากครับ

[erish2150]

ขอบคุณครับ :) คุณเขียนสิ่งที่ผมคิดไว้ได้ตรงมากเลยครับ

[bigcataroido]

แนวทางที่บังคับให้ทำงานแบบขนานบนพื้นฐานของ worktree น่าประทับใจมากครับ

ตอนผมต้องจัดการหลายตั๋วพร้อมกัน
ผมก็ใช้งานด้วยการผสม tmux + หลาย branch เพื่อแยกสภาพแวดล้อมของแต่ละงานเหมือนกัน
แต่สุดท้ายก็มีปัญหาเรื่องการจัดการสถานะที่พันกันอยู่เรื่อย ๆ

การรวม lifecycle ไว้ด้วย start/ship/merge แบบ parsec
กลับดูเหมือนจะเป็นแนวทางที่ช่วยลดความผิดพลาดได้มากกว่า

มีเรื่องที่สงสัยคือ
ในกรณีที่มีหลาย PR ถูกเปิดขึ้นมาพร้อมกัน แล้วลำดับการ merge เปลี่ยนไป
หรือเป็นสถานการณ์ที่ต้อง rebase นั้น stack sync จะทำงานอย่างไรครับ?

[erish2150]

ขอบคุณที่ให้ความสนใจ!

stack sync จะทำการ rebase ตามลำดับ topological order โดยอิงจากความสัมพันธ์แบบพ่อ-ลูก

วิธีการทำงาน

parsec start PROJ-1                 # อิงจาก main  
parsec start PROJ-2 --on PROJ-1     # อิงจากสาขา PROJ-1  
parsec start PROJ-3 --on PROJ-2     # อิงจากสาขา PROJ-2  
  
parsec stack sync                   # rebase อัตโนมัติตามลำดับด้านล่าง  
# 1. PROJ-1 → rebase ขึ้นไปบน origin/main  
# 2. PROJ-2 → rebase ขึ้นไปบนสาขา PROJ-1  
# 3. PROJ-3 → rebase ขึ้นไปบนสาขา PROJ-2  

โครงสร้างจะไล่วนแบบ BFS จาก root แล้วทำ rebase ให้ลูกแต่ละตัวขึ้นไปบนสาขาของพ่อ หาก main มีการอัปเดต การเปลี่ยนแปลงก็จะถูกส่งต่ออย่างเป็นธรรมชาติจาก root ลงมา

กรณีที่ลำดับการ merge เปลี่ยนไป

ปัจจุบันออกแบบมาโดยตั้งสมมติฐานว่าจะ merge จากด้านล่างของสแต็ก (พ่อ) ขึ้นไปก่อน หาก PR ตรงกลางถูก merge ก่อน ลูกของโหนดนั้นจะหา parent ไม่เจอในครั้งถัดไปที่รัน stack sync และจะล้มเหลว ในกรณีนี้
ต้องกำหนด base ใหม่ด้วยตนเอง

เมื่อเกิด conflict

หากเกิด conflict ระหว่าง rebase ระบบจะ rollback เฉพาะสาขานั้นด้วย rebase --abort แล้วให้ส่วนที่เหลือทำงานต่อ โดยจะแสดงผลลัพธ์เป็นตารางว่าทิกเก็ตใดสำเร็จ/ล้มเหลวบ้าง ดังนั้นจึงแก้เฉพาะตัวที่ล้มเหลวด้วยตนเองก็พอ