처음 Git을 배울 때 가장 헷갈리는 순간은 “저장했는데 왜 커밋이 안 됐지?”, “푸시는 또 뭐가 다른 거지?”, “브랜치를 만들었는데 어디로 갔지?” 같은 지점입니다. 특히 VSCode를 쓰면 터미널보다 쉬워 보이지만, Source Control 화면의 용어를 정확히 모르면 오히려 더 막히기도 합니다. 이 글은 VSCode Git 입문 관점에서 커밋, 푸시, 브랜치, 충돌 해결까지 가장 많이 만나는 흐름을 순서대로 정리한 가이드입니다.
핵심만 먼저 말하면, VSCode는 Git을 “대체”하는 도구가 아니라 Git을 더 쉽게 다루게 해주는 인터페이스입니다. 즉 파일 변경 확인 → 스테이징 → 커밋 → 원격 저장소로 푸시라는 기본 흐름은 그대로이고, 이를 VSCode Source Control 패널에서 눈으로 확인하며 처리하는 방식이라고 이해하면 훨씬 쉽습니다. VSCode Git 입문은 명령어를 모두 외우는 것보다, 지금 내가 어느 단계에 있는지 구분하는 것부터 시작하는 게 가장 중요합니다.
VSCode Git이 처음이라면 먼저 이해할 4단계
초보가 헷갈리지 않으려면 아래 4단계를 먼저 머리에 넣어두면 됩니다. VSCode Git 입문에서 가장 중요한 건 기능이 아니라 순서입니다.
| 단계 | 의미 | VSCode에서 보이는 위치 |
|---|---|---|
| 변경 확인 | 어떤 파일이 수정됐는지 확인 | Source Control의 Changes |
| 스테이징 | 커밋에 포함할 파일 선택 | Staged Changes |
| 커밋 | 변경 이력을 로컬 저장소에 기록 | 상단 메시지 입력창 + Commit |
| 푸시 | 로컬 커밋을 GitHub 같은 원격 저장소로 업로드 | Sync / Push / Publish Branch |
여기서 가장 많이 생기는 오해는 “저장하면 커밋까지 된 것 아닌가요?”입니다. 아닙니다. 저장은 파일만 디스크에 저장한 것이고, 커밋은 버전 기록을 남기는 별도 단계입니다. 또 커밋을 했다고 해서 GitHub에 자동 업로드되는 것도 아닙니다. 그다음 단계가 바로 푸시입니다.
처음 세팅: VSCode에서 Git이 안 보일 때 확인할 것
1) Git 자체가 설치되어 있어야 합니다
VSCode는 내장 Git 엔진이 아니라, 내 컴퓨터에 설치된 Git을 사용합니다. 그래서 Source Control이 비정상적으로 보이거나 저장소 기능이 안 뜬다면 먼저 Git 설치 여부를 확인해야 합니다.
git --version버전이 잘 나오면 정상입니다. 아무 반응이 없거나 command not found가 뜨면 Git 설치부터 먼저 끝내야 합니다.
2) 폴더를 “파일”이 아니라 “프로젝트 폴더”로 열어야 합니다
VSCode에서 단일 파일만 열어 놓으면 Git 저장소가 제대로 잡히지 않는 경우가 많습니다. 반드시 File > Open Folder로 프로젝트 루트 폴더를 열어 주세요. 그래야 .git 디렉터리를 인식하고 Source Control 패널이 정상적으로 작동합니다.
3) 사용자 이름과 이메일이 비어 있으면 커밋에서 막힐 수 있습니다
Git은 커밋 작성자 정보를 사용합니다. 처음 세팅이라면 아래 두 줄을 먼저 입력해 두세요.
git config --global user.name "내 이름"
git config --global user.email "내이메일@example.com"VSCode에서 커밋하는 가장 쉬운 방법
VSCode Git 입문에서 가장 먼저 익혀야 할 건 커밋입니다. 아래 순서대로만 하면 됩니다.
- 왼쪽 사이드바에서 Source Control 아이콘을 누릅니다.
- 변경된 파일 목록을 확인합니다.
- 커밋에 넣을 파일 옆 + 버튼을 눌러 스테이징합니다.
- 상단 입력창에 커밋 메시지를 적습니다.
- Commit 버튼을 누릅니다.
커밋 메시지는 “수정”, “업데이트”처럼 두루뭉술하게 쓰기보다, 나중에 봐도 바로 이해되게 적는 게 좋습니다.
- 좋지 않은 예: 수정, 테스트, 변경
- 좋은 예: 로그인 버튼 색상 수정
- 좋은 예: 회원가입 폼 유효성 검사 추가
- 좋은 예: README 설치 방법 업데이트
초보가 자주 하는 실수는 모든 파일을 무조건 한 번에 스테이징하는 것입니다. 가능하면 기능 단위로 나눠 커밋하는 습관을 들이면 나중에 되돌리거나 비교할 때 훨씬 편합니다. 이것이 VSCode Git 입문 단계에서 실력을 빨리 올리는 가장 좋은 습관입니다.
푸시(push)는 왜 따로 해야 할까?
커밋은 내 컴퓨터 안의 로컬 저장소에 저장하는 것이고, 푸시는 그 커밋을 GitHub 같은 원격 저장소로 올리는 단계입니다. 그래서 커밋까지 했는데 팀원이 못 보거나 GitHub 잔디가 안 찍히는 경우는 대부분 푸시를 안 했기 때문입니다.
커밋과 푸시 차이 한 번에 이해하기
| 구분 | 저장 위치 | 다른 사람이 볼 수 있나? |
|---|---|---|
| 커밋 | 내 컴퓨터의 로컬 저장소 | 아니오 |
| 푸시 | GitHub 등 원격 저장소 | 예 |
VSCode에서는 보통 상태 표시줄의 Sync, Source Control 메뉴의 Push, 또는 처음 원격 저장소에 연결할 때는 Publish Branch / Publish to GitHub 같은 버튼으로 이 단계를 처리합니다.
브랜치(branch)는 언제 만들고 어떻게 써야 할까?
브랜치는 쉽게 말해 “작업용 갈래”입니다. 메인 코드를 건드리지 않고 새 기능을 안전하게 만들 때 사용합니다. VSCode Git 입문에서 브랜치를 일찍 익히면 협업이 훨씬 쉬워집니다.
초보 추천 브랜치 규칙
- main: 배포 가능한 안정 버전
- feature/기능명: 새 기능 작업
- fix/버그명: 버그 수정
- docs/문서명: README나 문서 수정
예를 들어 로그인 화면을 만들고 있다면 feature/login-page 같은 이름을 쓰면 됩니다. 브랜치명은 누가 봐도 작업 목적이 드러나게 짓는 것이 좋습니다.
VSCode에서 브랜치 만드는 방법
- 하단 상태 표시줄의 현재 브랜치 이름을 클릭합니다.
- Create New Branch를 선택합니다.
- 브랜치 이름을 입력합니다.
- 필요하면 바로 Publish Branch로 원격에도 올립니다.
브랜치를 만들었는데 GitHub에서 안 보인다면, 대부분은 아직 푸시 또는 Publish Branch를 하지 않은 상태입니다. 이 지점이 초보가 가장 많이 막히는 대표적인 순간입니다.
충돌(conflict)은 무조건 무서운 게 아닙니다
충돌은 같은 파일의 같은 부분을 서로 다르게 수정했을 때 생깁니다. 즉 에러라기보다 “어느 변경을 남길지 선택해 달라”는 신호에 가깝습니다. VSCode는 충돌이 나면 충돌 파일을 Source Control에 표시하고, 에디터 안에서 선택 버튼이나 3-way merge editor로 해결할 수 있게 도와줍니다.
충돌이 나는 대표 상황
- 내가 수정한 파일을 다른 사람도 동시에 수정한 경우
- 오래된 브랜치에서 작업하다가 뒤늦게 main을 합치는 경우
- 한 줄만 바꿨다고 생각했는데 실제로는 같은 블록을 건드린 경우
VSCode에서 충돌 해결 순서
- 충돌 파일을 엽니다.
- 각 변경 내용을 비교합니다.
- Current / Incoming / Both 중 맞는 옵션을 선택합니다.
- 필요하면 직접 내용을 정리합니다.
- 파일 저장 후 다시 스테이징합니다.
- 커밋으로 병합 결과를 기록합니다.
중요한 건 “충돌 해결 후 저장만 하면 끝”이 아니라는 점입니다. 반드시 다시 스테이징하고 커밋해야 충돌 해결이 완료됩니다. 이 과정을 빼먹으면 계속 미해결 상태처럼 보일 수 있습니다.
초보가 가장 많이 막히는 7지점과 해결법
1) Source Control에 아무것도 안 떠요
대부분 Git이 설치되지 않았거나, 저장소가 아닌 폴더를 연 경우입니다. git --version으로 Git 설치를 먼저 확인하고, 프로젝트 루트 폴더를 다시 열어 보세요.
2) 커밋 버튼이 비활성화돼요
스테이징된 파일이 없거나, 커밋 메시지가 비어 있는 경우가 많습니다. 일부 설정에서는 메시지 없이 커밋이 제한되기도 하니 메시지를 먼저 입력해 보세요.
3) 푸시가 안 되고 인증창만 떠요
GitHub 인증 방식이 아직 정리되지 않은 상태일 수 있습니다. HTTPS 인증을 쓸지, SSH 키를 쓸지 먼저 정하고 한 방식으로 통일하는 것이 좋습니다. SSH가 익숙해지면 반복 로그인 스트레스를 크게 줄일 수 있습니다.
4) 브랜치를 만들었는데 GitHub에 안 보여요
브랜치 생성은 로컬 작업입니다. 원격 저장소에서 보이려면 Publish Branch 또는 Push까지 해야 합니다.
5) 변경 파일이 너무 많아서 뭐부터 커밋할지 모르겠어요
한 번에 다 올리기보다 기능 단위로 나누세요. 예를 들어 “버튼 색상 수정”과 “README 업데이트”는 अलग 커밋이 더 좋습니다. 이 원칙만 지켜도 히스토리가 훨씬 깔끔해집니다.
6) 충돌 화면이 너무 복잡해요
당황하지 말고 “내 변경”, “상대 변경”, “둘 다 반영” 셋 중 하나라고 생각하면 정리가 쉽습니다. 필요하면 merge editor를 열어서 좌우 비교 화면으로 확인하세요.
7) 되돌리고 싶은데 어디서 해야 할지 모르겠어요
아직 커밋 전이면 파일별로 변경 취소를, 이미 커밋했다면 Git 히스토리 기준으로 되돌리는 방법을 써야 합니다. 그래서 작은 단위 커밋이 특히 중요합니다.
초보에게 추천하는 실전 작업 순서
실무든 개인 프로젝트든 아래 순서로 하면 실수가 크게 줄어듭니다. VSCode Git 입문을 끝내는 가장 현실적인 루틴이기도 합니다.
- main에서 최신 내용 pull 받기
- 새 브랜치 만들기
- 작업 후 변경 파일 확인
- 기능 단위로 스테이징
- 의미 있는 메시지로 커밋
- 브랜치 푸시
- 필요하면 GitHub에서 Pull Request 생성
이 루틴을 반복하면 “어느 순간 꼬였는지 모르겠다”는 상황이 크게 줄어듭니다. Git은 어려운 도구가 아니라, 순서를 놓치면 갑자기 어려워지는 도구에 가깝습니다.
마무리: VSCode Git은 ‘버튼’보다 ‘흐름’을 익히면 쉬워집니다
VSCode Git 입문의 핵심은 버튼 이름을 외우는 것이 아닙니다. 변경 확인 → 스테이징 → 커밋 → 푸시 → 브랜치 → 충돌 해결이라는 흐름을 이해하는 것입니다. 이 흐름만 잡히면 VSCode 화면이 훨씬 단순하게 보이고, 터미널 명령어를 나중에 배워도 연결이 아주 잘 됩니다.
지금 막 시작하는 단계라면, 오늘은 딱 하나만 해도 충분합니다. 작은 텍스트 파일 하나를 만들고, VSCode에서 스테이징 → 커밋 → 푸시까지 직접 해보세요. 직접 한 번 해보는 순간 Git의 개념이 머리보다 손에 먼저 들어옵니다.
0 댓글