Show GN: git-parsec — 티켓 하나로 worktree 생성부터 PR 머지까지
(github.com/erishforG)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 등)에게 독립된 작업 환경을 주고 싶은 분
링크
- GitHub: https://github.com/erishforG/git-parsec
- 설치:
cargo install git-parsec
Rust로 작성되어 가볍고, 기존 git 저장소에 바로 적용할 수 있습니다.
피드백이나 질문 환영합니다!
댓글과 토론
최근에 병렬 워크트리 기술블로그를 보고 흥미가 생겼으나 구현 내용은 볼 수 없어 아쉬웠는데, 이 오픈소스로 한번 깊게 다뤄봐야겠네요!
아래는 제가 본 블로그 글입니다.
https://medium.com/ajd-tech/…
감사합니다! 블로그 작성하신 내용도 가볍게 봐도 굉장히 훌륭하게 작성해주셨네요.
기회가 된다면 보시고서 마음에 안 드시거나 개선하고 싶은 점 등 있으면 편하게 이슈 등록 혹은 PR 날려주세요!
병렬 worktree는 work dirty -> clean nicely 방식이라 생각하고,
이게 향후 주된 개발 방식이 되리라 생각합니다.
좋은 레포 같아요.
worktree 기반으로 병렬 작업을 강제하는 접근이 인상적이네요.
저도 여러 티켓을 동시에 처리할 때
각 작업 환경을 분리하려고 tmux + 여러 branch 조합으로 운영하고 있는데
결국 상태 관리가 계속 꼬이는 문제가 있었습니다.
parsec처럼 start/ship/merge로 lifecycle을 묶어버리는게
오히려 실수 줄이는 방향일 것 같네요.
궁금한 점이 있는데,
여러 PR이 동시에 올라간 상태에서 merge 순서가 바뀌거나
rebase가 필요한 상황에서는 stack sync가 어떻게 동작하나요?
관심 가져주셔서 감사합니다!
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로 롤백하고 나머지는 계속 진행합니다. 어떤 티켓이 성공/실패했는지 결과를 테이블로 보여주기 때문에, 실패한 것만 수동으로 해결하면 됩니다.