포스트

VCS Map — SVN·Git·Jujutsu와 lazygit·jjui의 레이어

SVN, Git, Jujutsu를 버전 관리 모델로 비교하고 git/lazygit, jj/jjui를 CLI·TUI 레이어로 분리해 관계를 정리한다.

VCS Map — SVN·Git·Jujutsu와 lazygit·jjui의 레이어

최신 도구 목록·대안·보완 관계·치트시트는 Devkit 도구 지도에서 탐색한다. 이 글은 비교의 맥락과 기존 링크를 보존하는 심화 참고 문서다. 새로운 도구 목록은 여기와 중복 관리하지 않는다.

버전 관리 도구는 VCS 자체와 그 인터페이스를 분리해서 봐야 관계가 선명해진다.

전체 레이어

1
2
3
4
5
6
7
8
9
10
11
Version Control System
├─ SVN
│  └─ svn CLI
│
├─ Git
│  ├─ git CLI
│  └─ lazygit TUI
│
└─ Jujutsu
   ├─ jj CLI
   └─ jjui TUI

즉 대응 관계는 다음과 같다.

1
2
3
SVN      ↔ Git      ↔ Jujutsu     VCS 레이어
svn      ↔ git      ↔ jj          CLI 레이어
           lazygit  ↔ jjui         TUI 레이어

모델의 변화

1
2
3
4
5
6
7
8
9
10
11
12
13
SVN
중앙 repository 중심
      ↓

Git
분산 repository + commit graph
branch / HEAD / index
      ↓

Jujutsu
분산 revision graph
change / revision / bookmark
Git backend 사용 가능

Jujutsu가 Git 저장소를 backend로 사용할 수 있다는 점 때문에 Git의 UI처럼 보이기 쉽지만, 사용자가 다루는 모델은 별도 VCS에 가깝다.

SVN

SVN은 중앙 서버의 repository가 중심이다.

1
2
3
Central SVN Repository
        ↕
 Working Copy

장점은 모델이 단순하고 중앙 통제가 명확하다는 점이다. 반면 브랜치·오프라인 작업·로컬 히스토리 조작은 Git 계열보다 유연하지 않다.

Git

Git은 각 로컬 clone이 repository를 가진다.

1
2
3
4
5
Remote
  ↕
Local Git Repository
  ↕
Working Tree

강점은 압도적인 생태계와 GitHub/GitLab 같은 hosting 플랫폼이다. 대신 branch, HEAD, index/staging, rebase 같은 개념이 겹쳐 학습 비용이 생긴다.

관련 글:

Jujutsu

Jujutsu는 revision graph를 중심으로 작업한다. Git backend를 사용하면 기존 Git repository와 GitHub 흐름을 유지하면서 다른 작업 모델을 사용할 수 있다.

1
2
3
4
5
Git repository format
        ↑ backend
     Jujutsu
     ├─ jj
     └─ jjui

대표적인 차이:

GitJujutsu
branch가 작업 흐름의 중심revision/change가 중심
staging/index가 중요working-copy commit 모델
충돌을 해결해야 진행하는 경우가 많음conflict 상태도 revision으로 다룰 수 있음
reflog 등으로 복구operation log를 적극적으로 사용
branchbookmark

Jujutsu의 내부 작업 모델은 Jujutsu(jj) — Git의 복잡함을 다른 작업 모델로 풀기에서 자세히 설명한다. 명령은 Devkit jj 치트시트를 참고한다.

lazygit과 jjui

둘은 같은 UI 레이어에서 비교할 수 있다.

1
2
3
4
Git                 Jujutsu
│                   │
├─ git CLI          ├─ jj CLI
└─ lazygit          └─ jjui
  • lazygit: Git을 조작하는 TUI
  • jjui: Jujutsu를 조작하는 TUI

따라서 jjui를 Git용 TUI로 보면 안 되고, Jujutsu를 쓸 때 비로소 의미가 있다.

선택 기준

  • 기존 Git/GitHub 흐름에 불편이 없다 → Git 유지가 기본값
  • rebase·squash·과거 revision 수정이 일상적이고 Git의 상태 모델이 번거롭다 → Jujutsu를 시험할 이유가 생김
  • 중앙집중형 repository 모델이 필요한 기존 조직/시스템 → SVN이 여전히 존재할 수 있음

핵심은 “어떤 TUI가 더 좋은가”보다 어떤 VCS 모델을 사용할 것인가를 먼저 정하는 것이다.

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.