Show GN: git-parsec — 티켓 하나로 worktree 생성부터 PR 머지까지

 (github.com/erishforG)
4P by erish2150 | ★ favorite | 댓글 6개

Git worktree 기반의 병렬 개발 워크플로우를 자동화하는 CLI 도구입니다.

해결하는 문제

브랜치 전환 없이 여러 티켓을 동시에 작업할 때, git worktree는 좋은 선택입니다.
하지만 실무에서 쓰려면 반복 작업이 많습니다:

  • worktree 생성하고 브랜치 이름 짓고 → parsec start PROJ-123 한 줄로
  • push하고 PR 만들고 티켓 링크 붙이고 → parsec ship PROJ-123 한 줄로
  • CI 확인하고 머지하고 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 머지 → worktree 자동 정리

주요 기능

트래커 연동

  • Jira / GitHub Issues — 티켓 제목 자동 반영, 상태 전이, 보드 뷰, 인박스
  • parsec ticket — 터미널에서 티켓 상세 조회
  • parsec board — Jira 스프린트 보드를 CLI로 확인

워크트리 관리

  • Shell 통합 — parsec switch로 worktree 간 cd 자동 이동
  • 스택 PR — --on 옵션으로 PR 체인 구성, stack sync로 일괄 rebase
  • Undo — 실수로 정리한 worktree도 한 방으로 복구

자동화

  • Release — 태그 + 머지 + GitHub Release + 체인지로그 자동 생성
  • Human / JSON / Quiet 출력 모드 — CI 스크립트 연동 용이
  • 27개 서브커맨드 — start, list, status, ship, merge, ci, diff, sync, adopt, rename 등

설치

cargo install git-parsec

또는 GitHub Releases에서 macOS / Linux 바이너리를 다운로드할 수 있습니다.

이런 분들에게 유용합니다

  • 여러 티켓을 동시에 작업하는 분 (worktree 기반 병렬 개발)
  • Jira + Git 사이의 반복 작업이 지겨운 분
  • 모노레포에서 컨텍스트 스위칭 비용을 줄이고 싶은 분
  • AI 에이전트(Claude Code 등)에게 독립된 작업 환경을 주고 싶은 분

링크

Rust로 작성되어 가볍고, 기존 git 저장소에 바로 적용할 수 있습니다.
피드백이나 질문 환영합니다!

함께 보면 좋은 글 β

puddingman220   [-]

최근에 병렬 워크트리 기술블로그를 보고 흥미가 생겼으나 구현 내용은 볼 수 없어 아쉬웠는데, 이 오픈소스로 한번 깊게 다뤄봐야겠네요!

아래는 제가 본 블로그 글입니다.
https://medium.com/ajd-tech/…

답변달기
erish2150   [-]

감사합니다! 블로그 작성하신 내용도 가볍게 봐도 굉장히 훌륭하게 작성해주셨네요.
기회가 된다면 보시고서 마음에 안 드시거나 개선하고 싶은 점 등 있으면 편하게 이슈 등록 혹은 PR 날려주세요!

답변달기
shaun0927   [-]

병렬 worktree는 work dirty -> clean nicely 방식이라 생각하고,
이게 향후 주된 개발 방식이 되리라 생각합니다.
좋은 레포 같아요.

답변달기
erish2150   [-]

감사합니다 :) 제가 생각했던 부분을 잘 적어주셨네요.

답변달기
bigcataroido   [-]

worktree 기반으로 병렬 작업을 강제하는 접근이 인상적이네요.

저도 여러 티켓을 동시에 처리할 때
각 작업 환경을 분리하려고 tmux + 여러 branch 조합으로 운영하고 있는데
결국 상태 관리가 계속 꼬이는 문제가 있었습니다.

parsec처럼 start/ship/merge로 lifecycle을 묶어버리는게
오히려 실수 줄이는 방향일 것 같네요.

궁금한 점이 있는데,
여러 PR이 동시에 올라간 상태에서 merge 순서가 바뀌거나
rebase가 필요한 상황에서는 stack sync가 어떻게 동작하나요?

답변달기
erish2150   [-]

관심 가져주셔서 감사합니다!

stack sync는 부모-자식 관계를 기반으로 위상 정렬(topological order) 순서대로 rebase를 수행합니다.

동작 방식

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 → origin/main 위로 rebase  
# 2. PROJ-2 → PROJ-1 브랜치 위로 rebase  
# 3. PROJ-3 → PROJ-2 브랜치 위로 rebase  

루트부터 BFS로 순회하면서 각 자식을 부모 브랜치 위로 rebase하는 구조입니다. main이 업데이트되었으면 루트부터 변경사항이 자연스럽게 전파됩니다.  

## merge 순서가 바뀌는 경우  

현재는 스택의 아래쪽(부모)부터 머지하는 것을 전제로 설계되어 있습니다. 만약 중간 PR이 먼저 머지되면, 해당 노드의 자식들이 다음 stack sync 때 부모를 찾지 못해 실패하게 됩니다. 이 경우  
수동으로 base를 재지정해야 합니다.  

## 충돌 발생 시  

rebase 중 충돌이 나면 해당 브랜치만 rebase --abort로 롤백하고 나머지는 계속 진행합니다. 어떤 티켓이 성공/실패했는지 결과를 테이블로 보여주기 때문에, 실패한 것만 수동으로 해결하면 됩니다.
답변달기