# LazyGit - 게으른 개발자를 위한 Git UI > Clean Markdown view of GeekNews topic #24293. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24293](https://news.hada.io/topic?id=24293) - GeekNews Markdown: [https://news.hada.io/topic/24293.md](https://news.hada.io/topic/24293.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-11T14:33:12+09:00 - Updated: 2025-11-11T14:33:12+09:00 - Original source: [bwplotka.dev](https://www.bwplotka.dev/2025/lazygit/) - Points: 12 - Comments: 1 ## Summary 터미널에서 **Git 워크플로를 시각적으로 제어**할 수 있게 해주는 `lazygit`은, CLI의 단순함과 GUI의 직관성을 절묘하게 결합한 **TUI 기반 오픈소스 도구**입니다. **일관성·발견성·상호작용성**을 핵심 설계 원칙으로 삼아, 복잡한 리베이스나 체리픽 같은 작업도 키 몇 번으로 처리할 수 있게 단순화했습니다. 특히 **vim 스타일 키바인딩**과 명확한 뷰 구조 덕분에 손이 기억하는 속도로 Git을 다룰 수 있으며, 이는 “개발 도구 UX는 얼마나 방해 없이 흐름을 유지시켜 주는가”라는 질문에 훌륭한 답을 제시합니다. Git CLI에 익숙하지만 더 빠른 피드백 루프를 원하는 개발자라면 한 번쯤 꼭 써볼 만한 도구입니다. ## Topic Body - **터미널 기반 Git UI 도구 ‘lazygit’** 은 명령줄의 단순성과 그래픽 인터페이스의 직관성을 결합해 빠르고 일관된 작업 환경 제공 - **일관성·발견성·상호작용성**을 중심으로 설계되어, 초보자도 기본 Git 개념만 알면 즉시 활용 가능 - **vim 스타일 키바인딩**과 명확한 시각적 구조로 빠른 탐색과 반복 작업 단축 - **라인 단위 패치, 인터랙티브 리베이스, 체리픽 등** 복잡한 Git 작업을 단순화해 생산성 향상 - **Go로 작성된 오픈소스 TUI 프레임워크 기반**으로, 다른 개발 도구 UX 설계에도 참고할 만한 사례 --- ### LazyGit의 등장 배경 - 작성자는 Neovim 실험 중 우연히 `lazygit`을 실행하면서 도구의 효율성을 발견 - 이후 모든 Git 워크플로를 `lazygit`으로 전환 - 기존에는 `git gui`, `gitk`, CLI를 혼합 사용했으나, 구식 UI와 불안정성으로 대체 도구 탐색 - `lazygit`은 단순하고 빠르며, CLI와 호환되는 구조로 신뢰성 확보 ### LazyGit의 주요 특징 #### 일관성 (Consistency) - 인터페이스는 여러 **‘뷰 박스’** 로 구성되어 항상 동일한 시각적 구조 유지 - 좌측 박스 선택 시 우측 내용이 연동되어 변경 - **Git 용어와 추상화**를 그대로 사용해 학습 곡선 완화 - 예: `bisect`, `hunk` 등 표준 Git 개념을 자연스럽게 익힐 수 있음 - **vim 키바인딩**(`h/j/k/l`, `q`, `/`, `y`, `c`, `a`, `f`, `p`, `r` 등)을 채택해 빠른 조작 가능 - 명령 수를 제한하고 “한 가지 일을 잘한다”는 **유닉스 철학**을 따름 #### 발견성 (Discoverability) - 실행 시 즉시 필요한 정보 표시 - 현재 저장소, 브랜치, 스테이징 상태, 최근 커밋, 스태시, 마지막 명령, 단축키 등 - 시각적으로 과부하 없이 정보를 제공해 **맥락 전환 최소화** - 하단 푸터나 `?` 키로 단축키를 즉시 확인 가능 - 사용자는 언제든 **현재 위치와 상태를 직관적으로 파악** 가능 #### 상호작용성 (Interactivity) - 복잡한 Git 작업을 **대화형 인터페이스**로 안내 - 예: 푸시 시 업스트림 차이 경고, 리베이스 시 인터랙티브 여부 확인 - **리베이스, 충돌 해결, 브랜치 전환** 과정에서 자동 확인 및 후속 조치 제안 - `pick/drop/squash` 명령을 직접 입력할 필요 없이 키 조합으로 조작 가능 - 최소한의 방해로 사용자의 신뢰와 속도 향상 ### 향상된 Git 워크플로 - `lazygit`은 새로운 워크플로를 추가하지 않고 **기존 Git 기능을 더 안전하고 빠르게 사용**하도록 개선 - **라인·헝크 단위 패치 선택** 기능으로 세밀한 코드 복원 가능 - 커밋 일부만 되돌리거나 분리 가능 - 주요 단축 워크플로 예시 - 기존 커밋 수정 및 푸시: `2 space A P enter` - 새 커밋 생성 및 푸시: `2 space c <제목> P` - 브랜치 리베이스: `3 r i ... m c` - 커밋 삭제: `4 d` - 커밋 분할: `4 enter enter <c-p> n <제목> enter` - 체리픽: `3 4 C 3 4 V` - 반복 사용 시 단축키가 자연스럽게 습관화되어 **작업 속도 대폭 향상** ### 개발 도구 UX에서의 교훈 - `lazygit`의 **단순성, 일관성, 발견성, 합리적 기본값, 상호작용성**은 훌륭한 개발 도구 설계 원칙 - **깊은 설정 가능성**, **확장성**, **오픈소스 기여 생태계**가 건강하게 유지 - 100% **Go 언어로 작성된 TUI 프레임워크(gocui)** 기반으로, 다른 도구 개발에도 활용 가능 - 유사한 UX 패턴을 적용한 새로운 CLI/TUI 도구 개발 가능성 제시 ### 결론 - `lazygit`은 단순한 Git UI를 넘어 **개발 생산성과 UX 설계의 모범 사례**로 평가 - AI 보조 기능이 발전하더라도, **정확성과 신뢰성이 필요한 버전 관리 영역**에서 여전히 핵심적 역할 유지 - 오픈소스 커뮤니티의 기여와 협업을 통해 지속 발전 중 - 누구나 사용·기여 가능하며, **빠르고 직관적인 Git 경험** 제공 ## Comments ### Comment 46192 - Author: neo - Created: 2025-11-11T14:33:13+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45878578) - 예전엔 **magit**, **neogit**, **lazygit** 같은 키보드 중심의 git TUI를 좋아했음 하지만 지금은 git 대신 **jujutsu(jj)** 를 사용하고 있음 jj CLI에 익숙해진 후엔 [jjui](https://github.com/idursun/jjui)를 쓰기 시작했음 커밋 분할이 자주 필요한데, [hunk.nvim](https://github.com/julienvincent/hunk.nvim) 플러그인이 아주 유용함 또 **jj conflict** 해결에는 [jj-diffconflicts](https://github.com/rafikdraoui/jj-diffconflicts)가 최고임 이제 jj를 쓰면 커밋 그래프를 코드 줄 옮기듯 자연스럽게 편집할 수 있음 - 여러 도구 링크 고마움. 혹시 **패치 시리즈에서 diff를 분리하거나 재조합**할 수 있는 다른 도구도 아는지 궁금함 오래된 커밋에서 불필요한 hunk를 제거하면 이후 커밋들에 연쇄 충돌이 생기는데, 이런 걸 자동으로 처리해주는 툴이 있을까 궁금함 - 나도 git에서 jj로 완전히 넘어왔음. 다만 **lazygit의 diff 보기**가 더 깔끔해서 그 부분만 아직 lazygit을 씀 파일별로 구분된 diff가 보기 좋아서 그게 유일한 이유임 - 나도 jj로 전환 중임. 아직 모든 프로젝트에 적용하진 않았지만 시간문제임 다만 **jj 전용 GUI**가 더 있었으면 좋겠음. 여러 변경사항을 한눈에 보고 싶을 때 gg를 쓰지만, **side-by-side diff**가 없음 git butler 영상을 보니 jj UI도 그런 식으로 발전하면 좋겠다는 생각임 드래그로 변경사항을 옮기거나, 인터랙티브하게 **split/rebase**할 수 있는 GUI가 있으면 좋겠음 - git의 문제는 **너무 비의견적(unopinionated)** 이라는 점임 팀마다 git flow가 다르고, 개발자들은 쓸데없이 미세 최적화에 빠지거나 배우길 꺼려함 그래서 결국 팀마다 git 전문가가 필요해지는 구조가 됨 차라리 한 가지 방식만 강제하는 도구가 있었으면 좋겠음 - 웃을 수도 있겠지만, 지금까지 써본 git UI 중 **SourceTree**만큼 좋은 건 없었음 간단한 작업을 할 때 CLI보다 훨씬 쾌적하고, **파일 상태와 히스토리 뷰**가 정말 뛰어남 hunk나 라인 단위로 stage/unstage도 쉬움 다만 리눅스 버전이 없는 게 아쉬움. 다른 툴 다 써봤지만 결국 다시 돌아오게 됨 최근엔 **lazygit**도 써봤는데, TUI 중에서는 꽤 괜찮았음 - **magit** 써봤는지? Emacs 기반이라 학습곡선이 있지만 완전히 키보드 중심이고, 지원하지 않는 워크플로우를 찾기 어려움 - 커밋할 때는 **Git Extensions의 Commit 뷰**가 최고였음 자동 새로고침이 없어서 CLI와 충돌하지 않음 [Git Extensions Commit 문서](https://git-extensions-documentation.readthedocs.io/en/main/commit.html) - 나는 **Sublime Merge**를 제일 좋아함. 빠르고, 깔끔한 UI, 모든 플랫폼에서 잘 돌아가고, 단일 라이선스 구매로 끝임 - **Fork**나 **Tower**가 SourceTree보다 훨씬 낫다고 생각함. 혹시 무료 툴만 써본 건 아닌지? - 세상에서 SourceTree보다 싫은 UI는 거의 없음 수많은 버그와 이상한 문제로 시간을 낭비했음. 제발 **SourceTree는 버려야 함** - git을 직접 쓸수록 **git CLI 인터페이스의 불합리함**을 더 느끼게 됨 2년째 **jj**를 쓰고 있는데, 이제 git CLI로 돌아갈 수 없을 것 같음 사람들이 git에 헷갈려서 문제를 만드는 걸 너무 자주 봐서, 그냥 다른 걸 쓰라고 권함 - 나도 jj를 여러 번 시도했지만 **워크플로우가 손에 익지 않아** 속도가 느려짐 에디터에서 변경사항을 나눠 커밋하는 걸 좋아하는데, jj는 에디터 통합이 부족해서 결국 커밋이 지저분해짐 - 이름 때문에 기피하지만 **GitHub Desktop**은 꽤 훌륭함 GitHub 외의 repo도 잘 작동하고, **커밋 수정과 파일/라인 단위 cherry-pick**이 쉬움 복잡한 작업마다 설명이 붙어있어 초보자에게 특히 좋음 병합이나 그래프 기능은 부족하지만, 그래도 git CLI보다 훨씬 낫다고 생각함 새 팀원이 들어오면 항상 GH Desktop을 쓰게 함. 실수도 줄고 이해도 빠름 - 나도 GH Desktop에 동의함. 기능 추가 속도는 느리지만 신중함 git에 자신 없는 사람에게는 최고의 선택임 반면 **git에 과신하는 주니어 개발자**들이 repo를 망치는 걸 너무 많이 봤음 그래서 팀원들에게 GH Desktop을 강력히 추천함 - GH Desktop의 **병합/충돌 처리와 그래프 부재**가 오히려 사람들이 피하는 이유 같음 - 많은 git 사용자가 [**git-absorb**](https://github.com/tummychow/git-absorb)를 모름 이건 어떤 git flow에도 잘 맞고, **staged 변경을 여러 커밋에 나누어 수정**할 때의 고통을 줄여줌 대부분의 TUI에는 이런 기능이 없음 - 유용해 보이지만, 나는 **magit**을 쓰기 때문에 커밋과 리베이스가 이미 빠름 rust 기반 도구는 **의존성이 너무 많아** 선호하지 않음 - 이건 **GNU/Debian repo**에도 포함되어 있음 - 몇 달 써봤는데, 커밋을 잘못 squash해서 repo가 반쯤 꼬이는 경우가 있었음 신뢰가 떨어져서 결국 안 쓰게 됨. **너무 마법처럼 동작**하는 게 오히려 불편함 - 나에겐 **히스토리의 명확성**이 더 중요함. 깔끔한 이름을 위해 기록을 다시 쓰는 건 좋은 생각이 아님 - 나는 여전히 [**tig**](https://jonas.github.io/tig/)를 선호함 기능은 적지만 **UI가 단순하고 빠름** 주로 incremental index 추가용으로 사용함 - 나도 15년 넘게 **hunk stage용으로 tig**를 써왔음 - **VS Code**는 무료, 크로스플랫폼, 그리고 이미 많은 사람이 쓰고 있음 git GUI도 잘 되어 있고, 일반적인 워크플로우는 모두 처리 가능함 평소엔 CLI를 쓰지만, 프로젝트를 VS Code로 열어두면 GUI로 하는 게 더 빠르고 직관적일 때가 많음 - 하지만 **VS Code 자체를 써야 한다는 점**이 문제라고 생각함 - **LazyVim + tmux** 조합이 git 사용 방식을 완전히 바꿔놓았음 ctrl-g를 누르면 현재 디렉토리에서 **tmux floating pane**으로 lazygit이 뜨게 설정했음 neovim 안으로 들어가거나 UI를 전환할 필요 없이 바로 git 작업 가능함 터미널 중심 워크플로우에서는 가장 **유연하고 매끄러운 경험**임 - 나도 최근 **tmux display-popup**을 알게 됨 `~/.tmux.conf`에 ``` bind-key C-g display-popup -E -d "#{pane_current_path}" -xC -yC -w 80% -h 75% "lazygit" ``` 를 추가하면 `ctrl-b ctrl-g`로 lazygit 팝업을 띄우고 `q`로 닫을 수 있음 - 나는 **음성 명령 + AI**로 git 작업을 함. 아니면 ctrl-r로 충분한 UI라고 생각함 - 아직 아무도 언급 안 했지만, [**Gitu**](https://github.com/altsem/gitu)도 꽤 괜찮은 클라이언트임