VS Code로 Git·GitHub 한 번에 배우기…개발 초심자 위한 완벽 가이드

GitHub가 개발 입문자를 위한 VS Code 기반 Git 사용 가이드를 공식 공개했다. 에디터 내장 기능만으로 저장소 초기화부터 커밋, 머지까지 모든 버전 관리 작업을 할 수 있도록 구성했다.

Git과 GitHub, 그것이 정확히 뭔가

많은 초급자가 혼동하는 부분이 있다. GitHub는 코드를 저장하는 '플랫폼'이고, Git은 그 코드를 '관리하는 도구'다. 쉽게 말해 GitHub는 클라우드 저장소, Git은 버전 관리 시스템(VCS)이다. Visual Studio Code(VS Code)는 Microsoft가 제공하는 무료 코드 에디터로, Git을 내장해 GitHub와 연동된다. 이 통합이 핵심인데, 개발자가 에디터 밖으로 나갈 필요 없이 모든 Git 작업을 처리할 수 있다는 뜻이다.

첫 저장소 만들기: 3단계

처음 VS Code에서 Git을 쓰려면 폴더를 저장소로 초기화해야 한다. 순서는 간단하다.

1. VS Code를 열고 왼쪽 사이드바의 탐색기(Explorer) 아이콘(상단)을 클릭한다.
2. 폴더 열기(Open Folder)를 눌러 업로드할 코드가 있는 폴더를 선택한다.
3. 소스 제어(Source Control) 패널(사이드바 3번째 아이콘)로 이동해 저장소 초기화(Initialize Repository)를 클릭한다.

이 순간 몇 가지가 달라진다. 먼저 화면 하단 왼쪽에 브랜치명이 표시된다. 기본값은 main이다. 브랜치명을 바꾸려면 명령 팔레트(Mac: Shift+Cmd+P, Windows: Ctrl+Shift+P)를 열고 "rename"을 검색해 Git: Rename Branch 명령을 실행한다. 새 이름을 입력하면 끝이다.

또 하나 주목할 점은 소스 제어 패널의 모든 파일 옆에 "U" 기호가 붙는다는 것이다. U는 'Untracked'의 뜻으로, "아직 저장소에 추가되지 않은 새 파일 또는 수정된 파일"이란 의미다. 파일을 추적하려면 파일명 옆의 + 버튼을 누르거나, 한 번에 모두 추가하려면 CHANGES 위의 + 버튼을 클릭한다.

이렇게 선택된 파일들은 '스테이징(Staging)'되며, 기호가 "A"(Added)로 바뀐다. 이제 GitHub에 업로드할 준비가 된 것이다. 실제 업로드(커밋)를 하려면:

1. 소스 제어 창 상단의 텍스트박스에 커밋 메시지(변경 내용 설명)를 입력한다. 선택적으로 Copilot 버튼을 눌러 AI가 메시지를 자동 생성하게 할 수도 있다.
2. 텍스트박스 아래의 Commit 버튼을 누르면 변경사항이 로컬 저장소에 기록된다.

브랜치: 새로운 기능을 안전하게 개발하는 법

대규모 앱이라면 새 기능을 추가할 때 main 브랜치가 아닌 별도의 '작업 브랜치'를 만든다. 이렇게 하면 실제 운영 중인 코드에 영향을 주지 않고 실험할 수 있다.

새 브랜치를 만드는 방법:

1. 명령 팔레트를 열고(Mac: Shift+Cmd+P, Windows: Ctrl+Shift+P) "create branch"를 입력한다.
2. Git: Create Branch… 명령을 선택한다.
3. 새 브랜치의 이름을 입력한다(예: new-features).
4. Enter를 누르면 VS Code가 자동으로 그 브랜치로 전환한다.

화면 왼쪽 아래를 보면 현재 브랜치명이 표시되므로 언제든 확인할 수 있다.

코드 변경 추적: 에디터의 시각적 신호

작업 브랜치에서 파일의 코드를 수정하면 에디터 우측에 색상 표시가 나타난다. 이것이 '거터(Gutter)' 영역이다.

• 초록 줄: 새로 추가한 코드
• 파란 줄(패턴 있음): 기존 코드를 수정한 부분
• 빨간 화살표: 삭제된 코드

이 시각적 피드백 덕분에 개발자는 파일을 한눈에 파악할 수 있다. 수정된 파일은 소스 제어 패널의 CHANGES 섹션에 자동으로 나타난다.

파일명 위에 커서를 올리면 4개의 버튼이 표시된다: 파일 열기 / 변경사항 취소 / 변경사항 스테이징 / 변경사항 확인. 여러 파일을 동시에 처리하려면 CHANGES 헤더 위에서 같은 버튼들을 사용하면 된다.

차이점 비교: Diff 뷰

변경 내용을 정확히 보고 싶을 때는 소스 제어 패널에서 파일명을 클릭한다. 그러면 변경 전후를 나란히 비교할 수 있다(좌우 분할 뷰).

다른 형식을 선호한다면:

1. Diff 뷰 우측 상단의 세 점(…) 메뉴를 클릭한다.
2. Inline View를 선택한다.

이 모드에서는 변경사항이 한 창에 모두 표시되므로 더 간결하다. 여기서 직접 수정도 가능하다.

변경 내용을 확인한 후 업로드하려면, 앞서 설명한 대로 변경사항을 스테이징하고 커밋하면 된다. 모두 마치면 소스 제어 패널이 깔끔해진다.

브랜치 머지: 작업을 메인으로 병합하기

지금까지 작업한 브랜치의 변경사항은 아직 main 브랜치에 반영되지 않았다. 작업 브랜치를 main으로 돌아가 보면 원래 코드만 있다.

변경사항을 메인 브랜치로 가져오려면 머지(Merge) 작업이 필요하다:

1. 화면 왼쪽 아래의 브랜치명을 클릭한다.
2. 드롭다운에서 main을 선택해 메인 브랜치로 전환한다.
3. 소스 제어 패널의 CHANGES 옆 세 점(…) 메뉴를 열고 머지 옵션을 실행한다.

의미: 개발 입문의 진입장벽을 낮추다

이 가이드가 중요한 이유는 개발자 경험(DX) 관점에서다. 과거 초급자들은 Git 명령어를 외워야 했고, 에디터와 터미널을 오가며 작업해야 했다. GitHub는 이제 VS Code의 내장 기능을 강화해, 마우스 몇 번으로 버전 관리의 전체 흐름을 체험하게 했다.

또한 GitHub Copilot과의 연동(커밋 메시지 자동 생성)은 "코딩은 하지만 Git은 어려운" 사용자층을 끌어안기 위한 전략으로 보인다. 진입장벽이 낮아질수록 더 많은 개발자가 GitHub 생태계에 머무르고, 결국 GitHub의 상품(Copilot Pro, GitHub Enterprise 등) 전환 기회가 늘어난다는 계산이다.

이 기사는 한국에서도 시사점이 크다. 국내 개발 교육은 여전히 "CLI 터미널에서 Git 명령어를 완벽히 암기해야 한다"는 기조가 강하다. 하지만 VS Code 같은 모던 에디터는 이미 초보자의 손을 잡고 있다. GitHub의 공식 튜토리얼 확대는 '비전공 입문자도 Git과 친해질 수 있다'는 신호를 보내는 것이다.

결국 이는 개발자 풀의 저변 확대 경쟁이다. Microsoft와 GitHub는 초급자 단계부터 강력한 툴로 습관을 들이게 함으로써, 중급·고급 단계에서의 고객 충성도를 높이려 한다.