VS Code에는 Git이 내장되어 있다. 그런데 왜 다른 것을 사용하는가?
공정한 질문입니다. Visual Studio Code는 기본적으로 Git 통합을 제공합니다. 파일 staging, commit 메시지 작성, 브랜치 전환, diff 확인, 심지어 merge 충돌 해결까지 에디터를 떠나지 않고 할 수 있습니다. GitHub Desktop은 세련되고 간소화된 Git 경험을 제공합니다. GitHub Codespaces와 Gitpod 같은 웹 기반 IDE는 매년 좋아지고 있습니다. 이 모든 옵션이 있는데, 전용 Git 클라이언트가 아직 존재할 이유가 있을까요?
짧은 대답은 예이지만, 모든 사람에게 해당되지는 않습니다. 더 긴 대답은 이러한 내장 및 경량 도구가 실제로 무엇을 제공하고 어디에서 한계가 있는지를 살펴봐야 합니다.
VS Code가 잘하는 것
전용 클라이언트를 옹호하기 전에, VS Code가 올바르게 하고 있는 것을 인정할 필요가 있습니다. Git 통합은 기본 사항을 원활하게 다룹니다. 어떤 파일이 변경되었는지 확인하고, 개별 또는 일괄로 staging하고, commit 메시지를 작성하고 push할 수 있습니다 -- 모두 Source Control 패널에서 가능합니다. 인라인 diff 뷰어는 깔끔하고 기능적입니다. GitLens 같은 확장 프로그램은 blame 주석, commit 히스토리 등을 추가합니다.
단순한 워크플로 -- 단일 브랜치, 정기적 commit, 가끔의 pull -- 에서는 VS Code의 내장 Git 지원이 정말로 충분합니다. 일일 Git 사용이 add, commit, push, pull에 한정된다면 다른 것은 필요 없을 수 있습니다.
하지만 Git은 그 이상의 것이 가능하며, 여기서 전용 클라이언트가 그 자리를 차지합니다.
commit 그래프: 전체 그림 보기
VS Code Git 통합의 가장 큰 한계는 시각적 commit 그래프의 부재입니다. VS Code는 commit의 평면 목록을 보여줍니다. 히스토리는 볼 수 있지만 그 형태는 볼 수 없습니다.
commit 그래프는 브랜치가 어떻게 갈라지고, 어디서 merge되며, 어떤 commit이 어떤 브랜치에 있고, 전체 히스토리가 어떻게 흐르는지 보여줍니다. 이 시각화는 장식이 아닙니다 -- 하나 이상의 활성 브랜치가 있는 리포지토리에서 무슨 일이 일어나고 있는지 이해하는 데 필수적입니다.
세 개의 기능 브랜치가 진행 중이고, 하나는 merge되었지만 아직 삭제되지 않았으며, 핫픽스가 main에서 릴리스 브랜치로 cherry-pick된 시나리오를 생각해 보세요. VS Code에서는 commit의 시간순 목록이 보이고 관계를 머릿속에서 재구성해야 합니다. 전용 Git 클라이언트에서는 전체 구조가 한눈에 보입니다: 어떤 브랜치가 앞서 있고, 어떤 것이 갈라졌으며, 각 merge가 정확히 어디서 일어났는지.
일부 VS Code 확장 프로그램이 그래프 시각화를 추가하려고 하지만, 에디터의 UI 제약에 의해 제한됩니다. 사이드바에 끼워 넣은 패널이나 webview 탭은 전용 Git 클라이언트가 제공하는 전체 창 전용 그래프에 비할 수 없습니다.
명령줄 없는 복잡한 작업
VS Code는 기본을 다루지만, 더 복잡한 작업이 필요할 때는 보통 터미널로 전환해야 합니다. 전용 Git 클라이언트는 이러한 작업을 시각적으로 처리합니다:
- 인터랙티브 rebase. commit 재정렬, squash, commit 메시지 편집, commit 삭제 -- 모두 드래그 앤 드롭이나 간단한 컨트롤로, 실행 전 결과의 명확한 미리보기와 함께.
- cherry-pick. 한 브랜치에서 특정 commit을 선택하여 다른 브랜치에 적용, 무엇이 선택될지 시각적 확인 제공.
- stash 관리. 각 stash에 무엇이 포함되어 있는지 완전한 가시성을 가지고 stash 생성, 확인, 적용, 삭제. VS Code는 stash를 기본 목록으로 표시하지만, 전용 클라이언트는 이를 일급 객체로 검사하고 관리할 수 있게 합니다.
- Bisect. 일부 전용 클라이언트는 어떤 commit이 버그를 도입했는지 추적하기 쉽게 만드는 시각적 bisect 인터페이스를 제공합니다.
- 서브모듈 관리. 올바른 명령어 구문을 기억하는 대신 명확한 상태 표시기로 서브모듈을 보고 업데이트.
이러한 작업 중 명령줄에서 불가능한 것은 없습니다. 하지만 시각적으로 수행하면 실수 위험이 줄어들고 프로세스가 빨라집니다. 특히 매일 수행하지 않아 정확한 구문을 기억하지 못할 수 있는 작업에서 그렇습니다.
멀티 리포지토리 워크플로
많은 개발자가 매일 여러 리포지토리에 걸쳐 작업합니다. 마이크로서비스 아키텍처, 프론트엔드와 백엔드 분리, 또는 지원 라이브러리와 함께하는 모노레포 -- 이것은 흔한 구성입니다. VS Code의 Git 통합은 열려 있는 워크스페이스에 한정됩니다. 리포지토리 간 전환은 워크스페이스를 전환하거나 새 창을 여는 것을 의미합니다.
전용 Git 클라이언트는 일반적으로 여러 리포지토리에 대한 탭이나 패널을 지원하여 컨텍스트를 잃지 않고 모니터링하고 전환할 수 있게 합니다. 프론트엔드 리포지토리에서 commit 작업을 하면서 API 리포지토리의 상태를 확인할 수 있습니다. 창을 열고 닫을 필요가 없습니다.
merge 충돌 해결
VS Code는 merge 충돌 해결을 크게 개선했습니다. "Accept Current", "Accept Incoming", "Accept Both" 버튼이 있는 인라인 충돌 에디터는 간단한 충돌에 잘 작동합니다. 하지만 충돌 파일이 많거나 양쪽 버전의 일부를 조합해야 하는 복잡한 merge에서는 전용 클라이언트의 3방향 merge 에디터가 훨씬 더 명확한 그림을 제공합니다.
적절한 3방향 merge는 기본 버전(공통 조상), 당신의 버전, 수신 버전을 나란히 보여줍니다. 이 컨텍스트는 충돌이 왜 발생했는지와 올바른 해결이 무엇인지 이해하기를 훨씬 쉽게 만듭니다. VS Code의 merge 에디터도 이 방향으로 발전했지만, 전용 Git 클라이언트는 수년에 걸쳐 이 워크플로를 다듬어 왔으며 일반적으로 더 성숙한 경험을 제공합니다.
대규모 리포지토리에서의 성능
소규모에서 중규모 리포지토리에서는 VS Code와 전용 클라이언트 간의 성능 차이가 미미합니다. 하지만 리포지토리가 커지면 -- 수천 개의 commit, 수백 개의 브랜치, 큰 바이너리 파일 -- 차이가 눈에 띕니다. 성능을 우선으로 구축된 네이티브 Git 클라이언트는 VS Code의 Git 통합이 지연되거나 응답하지 않게 만드는 리포지토리 작업을 처리할 수 있습니다.
이것은 특히 깊은 히스토리를 가진 리포지토리에서의 로그 탐색과 blame 작업에 관련됩니다. 시각적 그래프에서 수천 개의 commit을 스크롤하는 것은 부드러워야 하며, 이 작업을 위해 특별히 만들어진 도구는 Git이 추가된 범용 에디터보다 더 잘 최적화되어 있습니다.
반론: 단순함에도 가치가 있다
VS Code의 내장 Git에 대한 가장 강력한 논거를 인정하지 않는 것은 솔직하지 못할 것입니다: 이미 거기에 있다는 것. 설치할 추가 도구도, 관리할 추가 라이선스도, 애플리케이션 간 컨텍스트 전환도 없습니다. Git 워크플로가 단순한 개발자에게 전용 클라이언트를 추가하는 것은 불필요한 복잡성입니다.
대부분의 시간을 단일 브랜치에서 작업하고, 정기적으로 commit하며, rebase나 복잡한 merge 시나리오 관리가 드물다면, VS Code는 필요한 모든 것을 제공합니다. 모든 개발자가 시각적 commit 그래프나 3방향 merge 에디터를 필요로 하는 것은 아니며, 단순한 워크플로에 더 단순한 도구를 사용하는 것은 완전히 유효한 선택입니다.
전체 그림
전용 Git 클라이언트는 전체 그림을 원하는 개발자를 위해 존재합니다. 무엇이 변경되었는지뿐만 아니라 리포지토리의 히스토리가 어떻게 구조화되어 있는지 보여줍니다. 명령어 구문을 기억할 필요 없이 복잡한 작업을 시각적으로 처리합니다. 창 전환 없이 여러 리포지토리를 관리합니다. 완전한 컨텍스트로 merge 충돌을 해결합니다.
VS Code는 우연히 Git 지원을 포함하는 뛰어난 에디터입니다. 전용 Git 클라이언트는 Git 자체를 중심으로 처음부터 구축된 도구입니다. 차이점은 하나가 다른 것보다 낫다는 것이 아닙니다 -- 당신의 워크플로가 전용 도구가 제공하는 깊이를 요구하는지 여부입니다.
commit 목록을 보면서 브랜치가 어디서 갈라졌는지 알아내려고 눈을 가늘게 뜬 적이 있거나, 오늘 열 번째로 git log --oneline --graph --all을 입력한 적이 있거나, 무엇이 충돌할지 몰라서 merge를 두려워한 적이 있다면 -- 전용 Git 클라이언트를 시도해 볼 가치가 있습니다. 전체 그림을 보는 것이 Git과의 작업 방식을 완전히 바꿀 수 있다는 것을 발견할 수 있습니다.