Git 그래프를 가장 빨리 보는 방법은 터미널입니다. git log --graph --oneline --all --decorate를 실행하면 모든 브랜치가 선으로 그려지고, 한 줄에 커밋 하나씩, 브랜치와 태그 이름이 해당 커밋 옆에 표시됩니다. VS Code에서는 소스 제어 뷰에 기본으로 들어 있는 Source Control Graph를 쓰거나, Git Graph 확장을 설치하면 더 크고 클릭도 되는 그래프를 볼 수 있습니다. 둘 다 글 마지막에서 자세히 다룹니다.
“진행 상황 어때요?“라는 질문을 반기는 사람은 없습니다. 그런데 회사에서 프로젝트를 이끄는 입장에서는 진행 상황을 모르고 지나갈 수도 없죠. 제 타협점이 Git 그래프입니다. 누군가에게 묻기 전에 먼저 그래프를 봅니다. 대부분의 경우 답은 이미 거기 있습니다. 커밋 활동, 브랜치, 병합이 한눈에 보이고, 그걸 위해 회의를 잡을 필요도 없습니다.
그래프에서 실제로 읽을 수 있는 것#
찬찬히 본 적이 없는 분들을 위해 설명하면, 노드 하나가 커밋이고 갈라져 나가는 선이 브랜치이며, 전체가 프로젝트의 타임라인이 됩니다. 이 배치에 생각보다 많은 정보가 담겨 있습니다.
- 한 번 훑어보는 것만으로 활성 브랜치 수와 커밋 빈도가 보입니다.
- 갑자기 조용해진 브랜치나 몇 주째 병합되지 않은 브랜치는 대개 누군가 막혀 있다는 신호입니다. 이런 조기 경보는 값지죠.
- 병합 빈도는 팀의 협업 방식을 비춥니다. 병합이 잦다는 건 작업이 꾸준히 통합되고 있다는 뜻이고, 너무 오래 산 브랜치는 고립된 작업이 되어 있을 가능성이 높습니다.
방해는 줄고, 대화는 나아지고#
눈에 띄는 이득은 누구의 작업도 끊지 않고 상황을 알 수 있다는 겁니다. 더 큰 이득은 정말 대화가 필요해졌을 때 나타납니다. 추측이 아니라 그래프에서 이야기를 시작할 수 있거든요. “이 브랜치가 화요일부터 안 움직이던데, 뭐 막힌 거 있어요?“는 “진행 상황 어때요?“보다 훨씬 나은 첫마디입니다.
루틴을 공개해 두는 것도 도움이 됩니다. 저는 거의 매일 아침 슥 훑어보고, 일주일에 한 번 제대로 들여다봅니다. 팀도 그 리듬을 알고 있으니 아무도 놀라지 않습니다.
감시 도구로 만들지 말 것#
이 부분은 저 스스로에게도 계속 되뇌는 대목입니다. 커밋 수는 가치가 아닙니다. 공들인 커밋 하나가 요란한 커밋 50개를 이길 때도 있습니다. 모든 커밋이 보인다고 해서 모든 결정에 토를 달 자격이 생기는 것도 아니고요. 팀을 믿고, 패턴이 정말 수상할 때만 개입해야 합니다. 그리고 그래프를 대화에 끌어들일 때는 피드백의 출발점으로 써야지, 기소용 증거로 쓰면 안 됩니다.
터미널에서 그래프 보기#
Git만 있으면 됩니다.
git log --graph --oneline --all --decorate옵션별 의미는 이렇습니다.
--graph: 왼쪽에 브랜치와 병합 선을 그립니다.--oneline: 커밋 하나를 한 줄로, 짧은 해시와 메시지 첫 줄만 보여 줍니다.--all: 지금 있는 브랜치뿐 아니라 원격을 포함한 모든 브랜치와 태그를 보여 줍니다.--decorate: 브랜치와 태그 이름을 가리키는 커밋 옆에 표시합니다. 최근 Git은 출력이 터미널로 갈 때는 알아서 표시하지만, 이 옵션을 붙여 두면 파이프로 다른 명령에 넘길 때도 이름이 남습니다.
매일 아침 이걸 다 칠 수는 없으니 alias로 만들어 둡니다.
git config --global alias.graph "log --graph --oneline --all --decorate"
git graph오래된 저장소라면 그래프 전체는 스크롤이 끝나질 않습니다. 줄이는 방법 몇 가지입니다.
git graph --since="2 weeks ago" # 최근 2주만
git graph -20 # 최근 커밋 20개만
git log --graph --oneline main..feature # feature에는 있고 main에는 아직 없는 것
git log --graph --oneline --left-right main...feature # 양쪽 모두, < 와 > 로 구분마지막 두 줄은 두 브랜치 비교입니다. alias 대신 그냥 git log를 쓰는 이유는, --all이 들어가면 다른 브랜치가 전부 다시 딸려 오기 때문입니다. 점 두 개는 feature에는 있고 main에는 없는 것을 보여 줍니다. 점 세 개에 --left-right를 붙이면 서로 상대에게 없는 것을 양쪽 다 보여 주니, 오래 살아 있는 브랜치가 얼마나 멀어졌는지 금방 확인할 수 있죠.
VS Code에서 그래프 보기#
VS Code에는 그래프가 기본으로 들어 있습니다. 소스 제어 뷰(Ctrl+Shift+G)를 열면 그 패널 안에 Source Control Graph 섹션이 있습니다. 1.93 버전(2024년 8월)부터 생긴 기능입니다. 기본값으로는 현재 브랜치와 그 원격 브랜치를 따라가고, 그래프 제목 표시줄의 브랜치 선택기로 다른 브랜치를 추가할 수 있습니다. 가볍게 훑어보는 용도라면 이것으로 충분합니다.
모든 브랜치를 한 번에 보고 싶다면 mhutchie의 Git Graph 확장을 설치합니다(확장 뷰에서 “Git Graph” 검색). 상태 표시줄의 Git Graph 항목, 소스 제어 뷰 상단의 Git Graph 아이콘, 또는 명령 팔레트의 Git Graph: View Git Graph (git log) 중 아무거나로 열면 됩니다. 커밋을 클릭하면 바뀐 파일이 보이고, 한 커밋을 클릭한 뒤 다른 커밋을 Ctrl/Cmd+클릭하면 둘을 비교할 수 있습니다. 다만 이 확장은 2021년 이후 새 릴리스가 없어서, 기본 그래프도 알아 두면 좋습니다.
Git Graph 버튼이 안 보인다면 확장이 저장소를 못 찾았을 가능성이 큽니다. 기본 설정에서는 연 폴더 자체만 확인하고 하위 폴더까지는 찾지 않습니다. 저장소 폴더를 직접 열거나, 설정에서 git-graph.maxDepthOfRepoSearch 값을 올리세요.
그 밖의 도구#
웬만한 Git 도구에는 어딘가에 그래프가 있습니다. gitk --all은 Git 자체의 히스토리 브라우저입니다. GitHub, GitLab, Bitbucket에는 리포지토리 페이지에 “네트워크"나 “그래프” 뷰가 있고요. 데스크톱 클라이언트인 SourceTree(Atlassian의 무료 도구), GitKraken, Tower, Windows용 TortoiseGit에도 모두 그래프가 있습니다.
무엇을 고르든 목적은 같습니다. 진행 상황을 이해하는 것. 커밋 수를 세는 게 아니라요.