4 điểm bởi erish2150 2026-04-21 | 6 bình luận | Chia sẻ qua WhatsApp

Đây là công cụ CLI tự động hóa quy trình phát triển song song dựa trên Git worktree.

Vấn đề được giải quyết

Khi làm nhiều ticket cùng lúc mà không cần chuyển nhánh, git worktree là một lựa chọn rất tốt.
Tuy nhiên để dùng trong công việc thực tế thì có khá nhiều thao tác lặp lại:

  • tạo worktree, đặt tên nhánh → gói gọn trong một dòng parsec start PROJ-123
  • push, tạo PR, gắn link ticket → gói gọn trong một dòng parsec ship PROJ-123
  • kiểm tra CI, merge, dọn worktree → gói gọn trong một dòng parsec merge PROJ-123

Các thao tác lặp đi lặp lại trước đây nay được rút xuống thành những lệnh chỉ một dòng.

Quy trình làm việc cốt lõi

parsec start PROJ-123       # worktree + nhánh + liên kết ticket Jira  
# ... coding ...  
parsec ship PROJ-123        # push → tạo PR (tự động kèm tiêu đề/link ticket)  
parsec ci PROJ-123          # in bảng trạng thái CI  
parsec merge PROJ-123       # chờ CI → squash merge → tự động dọn worktree  

Tính năng chính

Tích hợp tracker

  • Jira / GitHub Issues — tự động áp dụng tiêu đề ticket, chuyển trạng thái, board view, inbox
  • parsec ticket — xem chi tiết ticket ngay trong terminal
  • parsec board — xem bảng sprint Jira bằng CLI

Quản lý worktree

  • Tích hợp shell — tự động di chuyển cd giữa các worktree bằng parsec switch
  • Stack PR — tạo chuỗi PR bằng tùy chọn --on, rebase hàng loạt với stack sync
  • Undo — khôi phục ngay cả worktree đã dọn nhầm chỉ với một lệnh

Tự động hóa

  • Release — tự động tạo tag + merge + GitHub Release + changelog
  • Chế độ xuất Human / JSON / Quiet — dễ tích hợp với script CI
  • 27 subcommand — start, list, status, ship, merge, ci, diff, sync, adopt, rename, v.v.

Cài đặt

cargo install git-parsec  

Hoặc có thể tải binary cho macOS / Linux từ GitHub Releases.

Phù hợp với những ai

  • Người làm nhiều ticket cùng lúc (phát triển song song dựa trên worktree)
  • Người đã chán các thao tác lặp đi lặp lại giữa Jira và Git
  • Người muốn giảm chi phí context switching trong monorepo
  • Người muốn cấp môi trường làm việc độc lập cho AI agent (Claude Code, v.v.)

Liên kết

Được viết bằng Rust nên nhẹ, và có thể áp dụng ngay vào kho git hiện có.
Rất hoan nghênh phản hồi hoặc câu hỏi!

6 bình luận

 
puddingman220 2026-04-22

Gần đây tôi đọc một bài blog kỹ thuật về worktree song song và thấy rất hứng thú, nhưng tiếc là không thể xem được nội dung triển khai, nên có lẽ phải thử tìm hiểu sâu hơn qua mã nguồn mở này thôi!

Dưới đây là bài blog tôi đã đọc.
https://medium.com/ajd-tech/…

 
erish2150 2026-04-22

Cảm ơn bạn! Nội dung bạn viết trên blog cũng được biên soạn rất tốt, chỉ đọc lướt qua thôi cũng thấy rất ấn tượng.
Nếu có dịp, sau khi xem mà bạn thấy có điểm nào chưa ưng ý hoặc muốn cải thiện thì cứ thoải mái tạo issue hoặc gửi PR nhé!

 
shaun0927 2026-04-21

Mình nghĩ worktree song song là cách làm theo kiểu đưa work từ trạng thái dirty về clean một cách gọn gàng,
và mình tin rằng đây sẽ trở thành phương thức phát triển chủ đạo trong tương lai.
Có vẻ là một repo rất hay.

 
erish2150 2026-04-21

Cảm ơn bạn :) Bạn đã viết rất đúng những gì tôi nghĩ.

 
bigcataroido 2026-04-21

Cách tiếp cận ép buộc làm việc song song dựa trên worktree thật sự rất ấn tượng.

Bản thân tôi khi xử lý nhiều ticket cùng lúc
cũng đang vận hành theo kiểu kết hợp tmux + nhiều branch
để tách riêng từng môi trường làm việc,
nhưng rốt cuộc vẫn gặp vấn đề trạng thái cứ liên tục bị rối.

Việc gom lifecycle thành start/ship/merge như parsec
có vẻ ngược lại còn là hướng giúp giảm sai sót.

Có một điều tôi thắc mắc là,
khi nhiều PR được mở cùng lúc mà thứ tự merge bị thay đổi
hoặc rơi vào tình huống cần rebase, thì stack sync sẽ hoạt động như thế nào?

 
erish2150 2026-04-21

Cảm ơn bạn đã quan tâm!

stack sync sẽ thực hiện rebase theo thứ tự sắp xếp topo dựa trên quan hệ cha-con.

Cách hoạt động

parsec start PROJ-1                 # dựa trên main  
parsec start PROJ-2 --on PROJ-1     # dựa trên nhánh PROJ-1  
parsec start PROJ-3 --on PROJ-2     # dựa trên nhánh PROJ-2  

parsec stack sync                   # tự động rebase theo thứ tự bên dưới  
# 1. PROJ-1 → rebase lên origin/main  
# 2. PROJ-2 → rebase lên nhánh PROJ-1  
# 3. PROJ-3 → rebase lên nhánh PROJ-2  

Cấu trúc là duyệt BFS từ nút gốc và rebase từng nhánh con lên trên nhánh cha. Nếu main được cập nhật thì các thay đổi sẽ tự nhiên được lan truyền từ nút gốc.  

## Trường hợp thứ tự merge bị thay đổi  

Hiện tại, công cụ được thiết kế với giả định sẽ merge từ phía dưới của stack (nhánh cha) trước. Nếu một PR ở giữa được merge trước, thì các nhánh con của nút đó sẽ không thể tìm thấy nhánh cha trong lần `stack sync` tiếp theo và sẽ bị lỗi. Trong trường hợp này,  
bạn cần chỉ định lại base thủ công.  

## Khi xảy ra xung đột  

Nếu xảy ra xung đột trong lúc rebase, chỉ nhánh đó sẽ được rollback bằng `rebase --abort`, còn các nhánh khác vẫn tiếp tục được xử lý. Vì kết quả sẽ được hiển thị dưới dạng bảng cho biết ticket nào thành công/thất bại, bạn chỉ cần xử lý thủ công những phần bị lỗi.