VS Code에서 Git 쓰기, 줄 단위 스테이징부터

Git을 터미널로만 쓰다 보면 커밋 전에 변경 내용을 훑어보는 일이 귀찮아진다. git diff를 치고 좁은 터미널에서 스크롤하는 대신, VS Code의 소스 제어 뷰에서는 파일별 변경이 나란히 보이고 한 파일 안에서 일부 줄만 골라 스테이징할 수도 있다. 이 글은 VS Code의 Git 기능 중 터미널로는 번거로운 것들을 중심으로 다룬다.

소스 제어 뷰가 하는 일

Ctrl+Shift+G로 소스 제어 뷰를 연다. 문서는 이곳을 "스테이징, 커밋, 변경 관리 같은 일반적인 Git 작업의 중심 허브"라고 설명한다.

변경된 파일 목록에서 파일을 클릭하면 좌우 비교 화면이 열린다. 문서 표현으로는 "변경을 효과적으로 검토하기 위한 나란히 놓인 파일 비교"다. 왼쪽이 이전, 오른쪽이 현재다. 여기서 바로 편집할 수 있다는 점이 터미널과 다르다. diff를 보다가 오타를 발견하면 그 자리에서 고친다.

스테이징은 파일 이름 옆의 + 아이콘으로 한다. 전부 스테이징하려면 변경 목록 제목 줄의 +를 누른다.

편집기 왼쪽 여백에 표시되는 색 막대도 알아두면 좋다. 추가된 줄, 수정된 줄, 삭제된 위치가 색으로 표시된다. 그 막대를 클릭하면 그 자리에서 이전 내용을 보여주고 되돌리기 버튼이 뜬다. 파일 전체를 되돌리지 않고 한 덩어리만 되돌릴 때 쓴다.

줄 단위 스테이징이 터미널 대비 가장 큰 이점이다

한 파일에 서로 다른 목적의 변경이 섞이는 일은 자주 일어난다. 기능을 고치다가 눈에 띈 오타를 같이 고치고, 로그도 한 줄 추가한 경우다. 이걸 한 커밋에 몰아넣으면 나중에 이력을 읽기 어렵다.

터미널에서는 git add -p로 해결하지만, 화면에서 덩어리를 보며 y와 n을 누르는 방식이 직관적이지는 않다. VS Code는 이걸 시각적으로 한다. 문서 설명대로 "더 세밀한 제어를 위해 파일의 diff 뷰에서 특정 줄이나 선택 영역을 스테이징"할 수 있다.

diff 화면에서 원하는 줄을 선택하고 우클릭한 뒤 Stage Selected Ranges를 고르면 그 부분만 스테이징된다. 나머지는 작업 디렉터리에 남는다. 이 상태에서 커밋하면 선택한 부분만 들어간다.

이 기능을 알고 나면 커밋 단위가 눈에 띄게 깔끔해진다. "일단 다 커밋하고 나중에 정리하자"가 줄어든다.

브랜치와 원격 작업은 상태 표시줄에서 끝난다

왼쪽 아래 상태 표시줄에 현재 브랜치 이름이 보인다. 클릭하면 브랜치 목록이 뜨고 골라서 전환한다. 새 브랜치 만들기도 같은 목록에 있다. 문서가 말하는 "하나의 워크스페이스 안에서 브랜치를 빠르게 전환"이 이것이다.

브랜치 이름 옆에는 동기화 상태가 표시된다. 위아래 화살표와 숫자로 가져올 커밋과 올릴 커밋 수를 보여준다. 문서 설명으로는 "상태 표시줄에 동기화 상태를 보여주고 소스 제어 뷰에 들어오고 나가는 커밋을 표시한다". 클릭하면 fetch, pull, push를 한 번에 처리하는 동기화가 실행된다.

개별 작업이 필요하면 소스 제어 뷰의 점 세 개 메뉴에서 고른다. Pull, Push, Fetch가 따로 있다.

여러 브랜치를 동시에 작업해야 한다면 worktree도 지원한다. 문서는 "서로 다른 브랜치를 위한 별도 작업 디렉터리를 만들기 위해 Git worktree를 사용"할 수 있다고 안내한다. 급한 수정 요청이 왔을 때 지금 작업을 stash하지 않고 다른 디렉터리에서 처리할 수 있다.

충돌 해결은 3방향 병합 편집기로 한다

병합 충돌이 나면 VS Code가 충돌 부분을 강조하고 선택지를 보여준다. 문서는 두 가지 방식을 안내한다. "인라인 편집기 동작"으로 처리하거나 "3방향 병합 편집기"를 쓰는 것이다.

인라인 방식은 충돌 위쪽에 뜨는 Accept Current Change / Accept Incoming Change / Accept Both Changes 링크를 누르는 것이다. 간단한 충돌은 이쪽이 빠르다.

복잡한 충돌은 3방향 병합 편집기가 낫다. 화면이 셋으로 나뉘어 내 변경, 상대 변경, 공통 조상이 각각 보이고 아래에 결과가 나온다. 어느 쪽이 무엇을 바꿨는지 한눈에 들어오기 때문에, 텍스트에 박힌 <<<<<<< 표시를 눈으로 파싱하는 것보다 훨씬 낫다.

충돌 해결에서 가장 흔한 실수는 양쪽을 다 받아들이고 중복 코드를 남기는 것이다. 병합 편집기는 결과 화면을 따로 보여주므로 이 실수를 알아채기 쉽다. 해결한 뒤 결과 화면을 한 번 읽는 습관을 들이면 된다.

파일 하나의 이력을 보는 타임라인

탐색기 아래쪽에 Timeline 뷰가 있다. 문서는 "탐색기 뷰의 타임라인 뷰가 특정 파일의 커밋 이력을 보여준다"고 설명한다.

이게 유용한 순간은 "이 줄이 왜 이렇게 됐지"를 추적할 때다. 파일을 열어둔 채 타임라인에서 과거 커밋을 클릭하면 그 시점과의 diff가 뜬다. 터미널에서 git log --follow -p 파일명을 치고 스크롤하는 것보다 빠르다.

줄 단위로 누가 언제 바꿨는지는 blame 표시로 본다. 커서를 둔 줄 끝에 커밋 정보가 흐리게 뜬다. 이 정보로 커밋을 찾아가면 그때의 맥락을 알 수 있다. 코드를 고치기 전에 그 코드가 왜 그렇게 됐는지 확인하는 습관은 대체로 손해를 보지 않는다.

최근에는 커밋 메시지를 AI로 생성하는 버튼도 붙었다. 소스 제어 뷰의 반짝이 아이콘이다. 나는 초안을 받아 고쳐 쓰는 정도로만 쓴다. 무엇을 바꿨는지는 도구가 알지만, 왜 바꿨는지는 사람만 안다. 커밋 메시지에서 정작 중요한 것은 후자다.

알아두면 편한 Git 관련 설정

기본값 그대로 써도 되지만, 몇 가지는 바꾸면 체감이 다르다. 사용자 설정에 넣는다.

{
  // 주기적으로 fetch 해서 원격 변경을 상태 표시줄에 알려준다
  "git.autofetch": true,
  // 스테이징한 것이 없을 때 커밋하면 전체 변경을 자동으로 스테이징할지 묻는다
  "git.enableSmartCommit": false,
  // 커밋 후 자동으로 push 하지 않는다 (실수 방지)
  "git.postCommitCommand": "none",
  // 브랜치를 전환할 때 저장되지 않은 변경이 있으면 경고
  "git.confirmSync": true,
  // 편집기 여백에 blame 정보를 흐리게 표시
  "git.blame.editorDecoration.enabled": true
}

git.enableSmartCommit은 취향이 갈린다. 켜두면 스테이징 없이 바로 커밋할 수 있어 빠르지만, 의도하지 않은 파일까지 들어갈 위험이 있다. 나는 꺼두고 항상 명시적으로 스테이징한다. 앞서 말한 줄 단위 스테이징을 쓰려면 어차피 꺼야 한다.

git.autofetch는 켜두면 편한데, 사설 저장소에 인증이 자주 만료되는 환경이라면 인증 팝업이 반복해서 뜰 수 있다. 그럴 때는 끈다.

커밋 전에 훑는 순서

도구 이야기를 했으니 습관 이야기로 마무리한다. 나는 커밋 전에 항상 이 순서로 본다.

먼저 변경된 파일 목록을 본다. 의도하지 않은 파일이 끼어 있는지만 확인한다. 빌드 산출물이나 로컬 설정 파일이 들어가려는 경우가 여기서 걸린다.

다음으로 각 파일의 diff를 연다. 특히 내가 기억하지 못하는 변경이 있는지 본다. 디버깅하다 남긴 로그, 주석 처리한 코드, 임시로 바꾼 상수가 여기서 잡힌다.

그다음 스테이징 단위를 나눈다. 성격이 다른 변경이 섞여 있으면 줄 단위 스테이징으로 쪼갠다. 커밋 두 개가 커밋 하나보다 나중에 읽기 쉽다.

마지막으로 커밋 메시지에 왜를 쓴다. 무엇을 바꿨는지는 diff에 다 있다. 메시지에 남길 것은 그 변경이 왜 필요했는지다. 여섯 달 뒤에 이 커밋을 열어볼 사람은 대개 나 자신이고, 그때 알고 싶은 것은 언제나 이유다.

이 네 단계가 1분 정도 걸린다. 그 1분이 나중에 이력을 되짚는 시간을 크게 줄인다.

그래도 터미널을 완전히 대체하지는 못한다

여기까지 GUI를 권했지만, 나는 둘을 섞어 쓴다. 기준이 있다.

보면서 판단해야 하는 일은 GUI가 낫다. diff 검토, 줄 단위 스테이징, 충돌 해결, 이력 추적이다. 눈으로 확인하는 것이 목적인 작업들이다.

정확한 동작을 지정해야 하는 일은 터미널이 낫다. rebase, cherry-pick, reflog로 복구하기, 특정 옵션이 붙은 reset 같은 것이다. GUI 버튼은 그 뒤에 어떤 명령이 실행되는지 명시하지 않는 경우가 있고, 되돌리기 어려운 작업일수록 무엇을 하는지 정확히 알고 눌러야 한다.

그리고 Git을 GUI로만 배우면 개념이 흐려진다. 스테이징 영역이 무엇인지, reset과 revert가 어떻게 다른지는 명령어로 겪어봐야 감이 온다. 버튼 이름만 아는 상태에서 사고가 나면 복구할 수가 없다.

VS Code의 Git 기능은 터미널을 대체하는 도구가 아니라 눈으로 확인하는 단계를 편하게 만드는 도구로 보는 것이 맞다. 그렇게 쓰면 둘 다 손에 익는다.

참고 자료

• Source Control — Visual Studio Code Docs — 소스 제어 뷰, 줄 단위 스테이징, 브랜치·worktree, 병합 충돌 해결, 타임라인
• User and workspace settings — Visual Studio Code Docs — git.autofetch 등 Git 관련 설정을 넣을 위치
• Terminal Basics — Visual Studio Code Docs — GUI 와 섞어 쓸 때 통합 터미널에서 Git 명령을 실행하는 환경