Evan의 Jujutsu 튜토리얼

 (evmar.github.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Git 사용 경험자가 단순하면서도 강력한 버전 관리 시스템 Jujutsu(jj) 를 간결하게 익힐 수 있도록 구성한 튜토리얼임
  • 학습에 앞서 Jujutsu를 사용할 이유가 궁금한 독자를 위해 별도의 Jujutsu 소개 글을 제공함
  • 대화체 입문서, 세부적인 공식 문서, 버전 관리 초심자용 자료 등 독자 수준에 맞는 대안도 안내함
  • 주제의 선택과 생략, 배치 순서를 신중하게 결정하기 위해 Evan Martin이 직접 집필함
  • 본문 작성에는 AI를 사용하지 않았으며, 대부분을 완성한 뒤 오류 점검에만 AI를 활용함

대상 독자와 학습 경로

  • Jujutsu는 단순하면서도 강력한 버전 관리 시스템이며, 튜토리얼에서는 이후 jj로 표기함
  • Git에 익숙한 독자를 대상으로 핵심에 집중한 간결한 학습 흐름을 제공함
  • 바로 학습하려면 튜토리얼 시작하기로 이동할 수 있으며, 도입 이유부터 살펴보려면 Jujutsu 소개 글을 참고할 수 있음

독자별 대안 자료

  • 이 튜토리얼의 방식이 맞지 않는다면 경험 수준과 선호에 따라 다음 자료를 선택할 수 있음

직접 집필과 AI 사용 범위

  • 전체 텍스트는 Evan Martin이 직접 작성했으며, 무엇을 포함하거나 생략할지와 어떤 순서로 배치할지를 사람이 신중하게 결정함
  • 본문을 만드는 데는 AI를 사용하지 않았고, 대부분을 작성한 뒤 오류를 확인하는 용도로만 활용함

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 솔직히 평판을 걸고 말하자면, jj를 일주일가량 써 봤지만 결국 Git을 직접 다루는 고통을 줄이려고 LLM에 도움을 청하게 됐고, 기존 작업 흐름을 충분히 대체한다는 느낌도 받지 못했음
    평소에는 git checkout, git add, git commit, git push 정도만 쓰며, 홍보 글에서 말하는 인덱스·스태시·여러 종류의 리셋·진행 중인 리베이스·일관성 없는 실행 취소 문제도 거의 겪지 않았고 모노레포도 잘 쓰지 않음
    Jujutsu의 주 대상은 누구인지, 또 jj를 능숙하게 쓰기까지 얼마나 걸렸는지 궁금하며 다음에는 최소한 그 정도 기간은 투자해 보고 싶음

    • LLM에는 구체적으로 어떤 작업을 도와달라고 하는지 궁금함
      나도 Git에서는 기본 작업 외에는 피하는 편이라, 스태시 후 브랜치를 바꾸는 대신 저장소를 다른 위치에 다시 복제했고 관련 변경만 골라 커밋하는 대신 git add --all로 전부 커밋하거나 편집기에서 변경을 되돌린 뒤 커밋하고 다시 적용했음
      직장에서 Mercurial을 7년 사용해 jj에 적응하기 쉬운 배경이 있었지만, 이제는 커밋 재배치와 여러 변경 관리가 간단해져 예전이라면 본능적으로 우회했을 복잡한 작업도 적극적으로 하게 됨
    • 무엇을 위해 버전 관리 시스템(VCS)을 쓰느냐에 따라 관점이 달라짐
      선형으로 개발한 코드를 가끔 스냅샷으로 남기는 정도라면 그 명령들로 충분하고, 완전한 VCS가 과해서 Dropbox만으로도 될 수 있음
      내게 VCS는 코드와 그 계층을 어떻게 사고했는지 보여 주는 서사 구축 도구이며, 주 독자는 동료이고 부 독자는 10년 뒤의 나임. jj는 이를 훨씬 마찰 없이 다룰 수 있게 해줌
    • LLM에 도움을 청해도 괜찮으며, 나도 필요한 기본 명령을 익힐 때까지 그렇게 했음
      용어와 기능의 기초를 잡으려고 안내서 몇 개를 처음부터 끝까지 읽고 개인 프로젝트에서 며칠간 꾸준히 사용하니 기본 작업은 꽤 능숙해졌고, VCS를 바라보는 방식도 달라졌음
      리팩터링이나 큰 기능을 개발할 때는 먼저 최종 목표까지 구현한 다음, 검토하기 쉽고 각각의 근거가 명확하도록 “모든 eslint 경고 수정”, “함수 노출을 위한 리팩터링”, “호출부 A를 새 함수로 전환”, “새 기능 추가” 같은 작은 변경으로 나눔. jj split 은 이 작업에 완벽하며, 이 기능 하나만으로도 jj를 쓸 이유가 충분함
      반면 git stash는 여러 스태시를 다루기 어렵고 충돌 시 저장한 코드를 잃을 수도 있는 위험한 사용성 함정이 많음. 낮은 커밋에 PR 피드백을 반영한 뒤 위의 커밋이나 PR을 리베이스하는 일도, 특히 스택형 PR에서는 진행 표시가 없고 중간에 멈추거나 다시 쌓기 어려워 악몽에 가까움. 그래서 스택형 PR 관리는 여전히 Graphite를 사용함
    • jj에서 가장 크게 얻은 이점은 리베이스 처리 방식임
      유기화학 전공 대학원생이 논문 작업용 브랜치를 4년간 병합이나 리베이스 없이 개발해 main보다 수천 커밋 뒤처진 상태에서 학위 심사를 앞두고 병합해야 했음. 거의 모든 커밋에서 충돌이 나므로 Git으로는 1~2주가 걸리고, 사흘째 긴급 버그가 들어오면 리베이스를 중단해 버그를 고친 뒤 처음부터 다시 시작해야 했으며, 3주 뒤 끝냈을 때는 최신 main에 맞추려고 또 리베이스해야 했음
      jj에서는 병합 충돌이 일급 객체라 여유 있을 때 해결할 수 있고, 도중에 새 커밋으로 이동해 긴급 버그를 고쳐도 진행 상황을 잃지 않음. Git에서 일주일 걸릴 리베이스를 하루 만에 끝낼 수 있었고, 한 번은 합쳐도 아무 변화가 없는 연속된 200개 커밋을 찾아내 수만 줄의 충돌을 이틀간 처리하던 작업을 1분도 안 돼 통째로 버렸음. 리베이스 중에도 main을 갱신하고 작업 중인 브랜치를 최신 main 위로 옮길 수 있음

  • Git에 너무 익숙해 가끔 명령을 찾아보는 정도인 내게도 이 글은 처음으로 흥미롭게 느껴진 Jujutsu 소개 글임
    이전 글들은 주로 “끔찍한 Git 명령줄 인터페이스에서 벗어날 수 있다”로 시작했는데, Git의 특이한 점과 다른 이들의 어려움은 이해해도 그런 표현 때문에 Jujutsu를 로맨스 소설이나 비프 빈달루처럼 나와 무관한 것으로 여겼음

    • jj의 즐거움을 설명하기 어려운 이유는 모든 VCS에 당연히 있다고 여겼던 암묵적 특성들이 실제로는 그렇지 않았고, 원자적 동작이 훨씬 단순하기 때문임
      좋은 홍보 문구를 만들기 어려우니 결국 “Git이 아니다”라는 말이 설명을 전부 차지하게 되며, 나 역시 이를 제대로 설명하지 못하는 편임
    • Git에서는 Sublime Merge GUI와 몇 가지 사용자 정의 명령을 이용하면 여기서 말하는 문제를 거의 해결할 수 있음
      다른 Git GUI와 달리 실제 Git 명령을 최대한 그대로 따르면서 난해한 문법만 메뉴와 버튼으로 바꾸고, 각 동작에 해당하는 명령도 숨기지 않고 상태 표시줄에 기록해 줌. Sublime JJ가 나온다면 즉시 갈아탈 생각임
    • 내가 jj를 써 보고 싶게 만든 표현은 항상 대화형 리베이스 상태인 Git이었음
답변달기