이 글에서는 Git이 무엇이고 왜 필요한지 알아보고, GitHub에 첫 저장소를 만들고 작업 환경을 설정합니다. Git은 일부러 IDE 그래픽 인터페이스로 다룹니다. 처음에는 이쪽이 한눈에 보이고 부담도 적으며, 수십 개의 명령어를 외울 필요도 없습니다.
예시와 화면 캡처는 JetBrains IDE 기준입니다. 메뉴 이름과 위치는 사용 중인 버전에 따라 다를 수 있습니다. 연습할 때는 별도의 학습용 저장소를 사용하세요. 실제 프로젝트에서는 해당 프로젝트의 브랜치, 커밋, 변경 사항 전송 규칙을 따르세요.
이 방식에는 또 다른 의미도 있습니다. Claude Code도 내부적으로는 Git 작업을 똑같이 수행합니다. 다만 콘솔에서 명령어를 사용하죠. 커밋하거나 브랜치를 만들고 변경 사항을 보내자고 제안할 때, 그 뒤에는 일반적인 Git 명령어가 있습니다. IDE 버튼 뒤에서 무슨 일이 일어나는지 알면 Claude Code가 제안하는 내용도 이해할 수 있고, 직접 확인한 뒤 판단해서 승인할 수 있습니다.
버전 관리는 왜 필요할까요?
프로젝트 작업을 시작하면 코드가 작동하는 게 가장 중요하다고 생각하기 쉽습니다. 하지만 얼마 지나지 않아 코드가 안정적으로 작동하는 것보다 바뀌는 일이 더 잦다는 걸 알게 됩니다. 버그를 고치고, 기능을 추가하고, 생각을 바꿔 되돌렸다가 다시 추가합니다.
직접 프로젝트를 작업한다고 생각해 보세요. 실험을 시작하기 전까지는 모든 게 순조롭습니다. 뭔가 바꾸고 싶지만 현재 작동하는 버전을 망가뜨릴까 걱정됩니다. 어떻게 할까요? 프로젝트를 복사하면 되겠죠. 그러다 보면 디스크에 이런 걸작들이 생깁니다.
MyProject/
├── main.py
├── main_backup.py
├── main_final.py
├── main_final2.py
├── main_really_final.py
├── main_really1_really_final2.py익숙한가요? 이번에는 친구 한 명이 프로젝트에 합류했다고 해 보죠. 그 친구도 파일을 복사하는데, 자기 방식대로 합니다. 어느 버전이 가장 최신이고 제대로 작동하는지 어떻게 알 수 있을까요? 누가 무엇을 바꿨는지, 실험이 잘 안 됐을 때 어떻게 되돌릴지도요.
저장된 이력이 없으면 파일 복사본을 일일이 비교해야 합니다.
- 작업 중인 코드를 잃어버리거나 혼동하기 쉽습니다.
- 저장된 버전을 찾아 복구할 일관된 방법이 없습니다.
- 두세 명이 함께 작업하기 어렵습니다.
- 실험을 망설이게 되고 혼란스러워집니다.
Git 같은 버전 관리 시스템은 바로 이런 문제를 해결합니다.
영상 - 터미널에서 배우는 Git 기초
이 영상은 터미널에서 Git을 사용하는 방법을 탄탄하게 익히도록 도와줍니다. IDE 버튼 뒤에서 실제로 어떤 일이 일어나는지 이해할 수 있습니다.
영상 예제는 Java로 되어 있지만 Git의 기본 작업은 언어와 관계없이 같습니다.
Git이란 무엇인가요? - 기본 개념
Git은 버전 관리 시스템입니다. 개발 중 코드 변경 사항을 추적하는 데 사용합니다. 파일의 여러 버전을 저장하고, 여러 사람이 하나의 프로젝트에서 함께 작업하도록 도와줍니다.
저장소(repo)는 프로젝트의 전체 이력, 즉 모든 변경 사항과 파일 버전이 저장되는 곳입니다.
커밋(commit)은 추적 중인 프로젝트 내용을 저장한 스냅샷입니다. 커밋에는 메시지, 작성자 정보, 부모 커밋과의 연결이 담깁니다. 커밋하지 않았거나 무시된 파일은 이 스냅샷에 포함되지 않습니다. 이력을 통해 이전에 저장한 버전을 찾고 복원할 수 있습니다.
각 커밋은 프로젝트의 스냅샷으로, 이전 커밋의 뒤를 이어 순차적인 변경 이력을 만듭니다.
브랜치(branch)는 한 개발 라인의 현재 커밋을 가리키는 이름입니다. 예시에서는 기본 브랜치 이름을 main으로 사용합니다. 여러분의 저장소에서는 이름이 다를 수 있습니다. 이름은 설정과 저장소를 만든 방식에 따라 정해집니다.
기본 브랜치 main에서 병렬 개발을 위한 develop 브랜치를 분기합니다. 작업이 끝나면 develop의 변경 사항을 다시 main에 병합합니다.
Git 주요 명령어 - 내부에서는 무슨 일이 일어날까요?
아래는 터미널에서 Git을 사용할 때 주로 쓰는 명령어입니다. 우리는 IDE의 그래픽 인터페이스를 사용하겠지만, 각 작업의 바탕이 되는 명령어를 알아 두면 도움이 됩니다. Git은 버튼을 누를 때마다 이 명령어를 실행하며, Claude Code도 여러분의 저장소에서 작업할 때 같은 명령어를 사용합니다. 내부에서 벌어지는 일을 보여 주는 예시로 살펴보세요.
| 명령어 | 기능 |
|---|---|
git init | 현재 폴더에 새 Git 저장소를 초기화합니다. |
git clone | URL에 있는 저장소를 새 폴더에 복사합니다. |
git status | 변경된 파일, 커밋할 준비가 된 파일, Git이 아직 추적하지 않는 파일을 보여 줍니다. |
git add | 다음 커밋을 위해 파일을 인덱스(staging)에 추가합니다. |
git commit | 준비된 변경 사항을 새 이력 스냅샷으로 기록합니다. |
git push | 로컬 저장소의 커밋을 원격 저장소로 보냅니다. |
git pull | 설정에 따라 변경 사항을 가져와 현재 브랜치에 통합합니다. |
git fetch | 서버에서 변경 사항을 내려받지만, 아직 브랜치에 병합하지는 않습니다. |
git branch | 브랜치를 표시하거나 만들고 삭제합니다. |
git checkout / git switch | switch는 브랜치를 전환합니다. checkout은 특정 커밋을 열거나 파일을 복원할 수도 있습니다. |
git merge | 지정한 브랜치의 변경 사항을 현재 브랜치에 병합합니다. |
git log | 커밋 이력을 보여 줍니다. |
git diff | 옵션 없이 실행하면 작업 파일과 인덱스를 비교합니다. 인덱스에 준비된 변경 사항은 따로 확인합니다. |
git restore | 선택한 파일을 복원합니다. 기준을 지정하지 않으면 작업 파일은 최신 커밋이 아니라 인덱스의 내용으로 복원됩니다. |
git reset | 인덱스나 현재 브랜치의 위치를 바꿉니다. 결과는 명령어 형식과 모드에 따라 다릅니다. |
git stash | 완료되지 않은 변경 사항을 잠시 보관해 나중에 다시 이어서 작업할 수 있게 합니다. |
git remote -v | 프로젝트가 연결된 원격 저장소를 보여 줍니다. |
git config | 커밋 작성자의 이름과 이메일 같은 Git 설정을 관리합니다. |
명령어를 전부 외울 필요는 없습니다. 처음에는 IDE와 에이전트의 작업이 Git 명령어를 바탕으로 한다는 점만 알아도 충분합니다. 인터페이스에서 한 번의 동작이 여러 명령어를 실행할 수도 있습니다. 예를 들어 Commit으로 변경 사항을 기록하면 git commit이 실행되고, Push 버튼을 누르면 git push가 실행됩니다.
- 작업 파일
- git add → 인덱스
- git commit → 이력
- git push → 서버
그림은 변경 사항을 보내는 과정을 보여 줍니다. add로 내용을 준비하고, commit으로 로컬에 기록한 다음, push로 커밋을 보냅니다. 반대 방향의 pull은 원격 커밋을 가져와 설정에 따라 현재 브랜치에 통합합니다.
Claude Code가 대신 수행하는 작업도 같은 원리입니다. 커밋하고 변경 사항을 보내겠다고 하면, 실제로는 git add, git commit, git push를 실행합니다. IDE의 같은 창에서 결과를 확인할 수 있습니다.
코드의 네 가지 상태
버전 관리를 사용하면 코드가 논리적으로 네 가지 상태를 거칩니다.
1. 작업 디렉터리(Working Directory). 지금 컴퓨터에서 편집 중인 프로젝트 파일입니다.
2. 스테이징 영역(Staging Area). 다음 커밋에 포함할 내용입니다. JetBrains에서는 변경 목록으로 작업하거나 별도의 staging 모드를 켤 수 있습니다. 일반 Commit 창의 체크박스는 커밋할 내용을 선택하는 것이지, 이미 Git 인덱스에 들어갔다는 뜻은 아닙니다.
3. 로컬 저장소(Local Repository). 컴퓨터에 있는 코드 이력의 개인 사본입니다. 인터넷이 없어도 여기서 커밋, 브랜치, 병합 작업을 할 수 있습니다.
4. 원격 저장소(Remote Repository). GitHub, GitLab, Bitbucket 같은 서비스에 있는 중앙 코드 저장소입니다. 코드를 안전하게 보관하고 팀 작업의 기반이 됩니다.
Claude Code가 새 파일을 추적하도록 추가하자고 하면, 파일을 작업 디렉터리에서 staging으로 옮깁니다. 이때 실행되는 명령어가 git add입니다. 추가하는 시점의 파일 내용이 준비되므로, 이후 수정한 내용은 다시 준비해야 합니다. 파일을 추가할 필요가 없다면(예: 임시 파일이나 불필요한 파일) 거절해도 됩니다.
Git과 GitHub는 어떻게 다를까요?
두 개념을 분명히 구분하는 것이 중요합니다. Git은 컴퓨터에서 로컬로 작동하며(인터넷이 없어도 됩니다) 파일 버전을 추적하는 프로그램입니다. GitHub는 Git 저장소의 원격 사본을 보관하는 클라우드 서비스(웹사이트)입니다.
GitHub에서는 저장소를 만들고 변경 사항을 추적하며 다른 사람과 함께 코드를 작업할 수 있습니다. 요즘 개발자에게 GitHub 프로필은 채용 담당자에게 보여 줄 수 있는 중요한 포트폴리오의 일부입니다.
GitHub에 첫 저장소 만들기
1단계. https://github.com에 접속해 가입하세요.
2단계. New repository 버튼을 눌러 새 저장소를 만드세요.
3단계. 저장소 설정을 지정하세요.
- 저장소 이름 - 의미 있는 이름을 정하세요.
- Public 또는 Private - 공개 범위를 신중하게 선택하세요. Public은 누구나 볼 수 있고, Private은 접근이 제한됩니다. 공개할 계획이 없는 개인 연습용이라면 Private을 선택할 수 있습니다.
- Add a README file - 새 빈 프로젝트라면 README를 추가해 두면 편리합니다. 이미 로컬 이력이 있는 프로젝트를 올릴 예정이라면, 서로 독립적인 초기 이력 두 개가 생기지 않도록 README 없이 빈 원격 저장소를 만드세요.
- Add .gitignore - 프로젝트 기술에 맞는 템플릿을 선택하세요. 드롭다운 목록에는 주요 언어용 템플릿이 준비되어 있습니다. 이 부분이 중요합니다. 빌드 도구와 패키지 관리자는 임시 파일과 캐시를 많이 만드는데, 이런 파일이 저장소에 쌓이면 안 됩니다. 템플릿을 사용하면 Git이 해당 파일을 무시합니다.
- Choose a license - 건너뛰어도 됩니다.
Create repository를 누르세요.
4단계. 완료했습니다. 첫 원격 저장소가 만들어졌습니다.
Git 설치 및 설정
이후 설명은 IntelliJ IDEA 화면을 기준으로 합니다. 다른 JetBrains IDE에도 비슷한 기능이 있지만, 버튼 위치와 메뉴 이름은 버전에 따라 다릅니다. 작업 이름을 기준으로 삼으세요. IDE의 작업 검색으로 찾을 수 있습니다.
Git을 사용하려면 먼저 설치해야 합니다. JetBrains IDE를 사용 중이라면 시스템에서 Git을 찾지 못했을 때 설치를 제안할 가능성이 큽니다. 동의하는 것이 가장 간단합니다.
File | Close Project를 선택해 현재 프로젝트를 닫으세요. 시작 화면(Welcome Screen)에서 Clone Repository를 누릅니다. 버전에 따라 버튼 이름이 Get from VCS일 수 있습니다.
Git을 직접 설치하려면 공식 사이트(https://git-scm.com/downloads)에서 다운로드하세요.
알아둘 점
첫 커밋을 만들 때 Git에는 작성자 이름과 이메일이 필요합니다. 이는 커밋에 붙는 서명이지 계정 로그인 정보가 아닙니다. GitHub 프로필과 연결하려면 계정 설정에서 인증한 이메일을 사용하세요. 개인 이메일을 공개하고 싶지 않다면 GitHub가 제공하는 noreply 주소를 쓸 수 있습니다.
GitHub는 이메일을 기준으로 커밋을 프로필에 연결합니다. 이메일이 일치한다고 해서 활동 그래프에 반드시 기록되는 것은 아닙니다. 추가 조건이 있습니다.
Claude Code가 Git과 GitHub를 직접 다루려면 무엇을 설치해야 할까요?
로컬 커밋과 브랜치에는 Git만 설치되어 있으면 됩니다. GitHub 로그인은 필요하지 않습니다. 원격 저장소에서 작업하려면 저장소에 접근할 수 있도록 설정하세요. GitHub CLI (gh)는 PR을 비롯한 GitHub 기능을 위한 추가 도구이지, Git의 필수 구성 요소는 아닙니다.
1. Git. 로컬 이력을 다룰 때 필요합니다. IDE를 통해 설치하거나 Git 공식 사이트에서 다운로드하세요.
2. GitHub CLI (gh)는 GitHub의 공식 명령줄 도구입니다. Claude Code는 이 도구로 브라우저를 열지 않고 터미널에서 pull request를 만들고, issues를 읽고, 검사 상태를 확인할 수 있습니다. 설치 방법은 운영체제에 따라 다릅니다.
운영체제별 설치 안내는 GitHub CLI 공식 페이지에서 확인할 수 있습니다. 도구를 설치한 뒤 gh --version 명령어로 사용할 수 있는지 확인하세요.
GitHub CLI를 선택했다면 접근 설정을 시작하고 안내에 따라 진행하세요. GitHub.com에서는 HTTPS와 브라우저 로그인을 선택할 수 있습니다.
# 터미널에서 GitHub 계정에 로그인
gh auth loginClaude Code는 이력을 다룰 때 git을, GitHub 기능에는 gh를 사용할 수 있습니다. GitHub 작업 방식으로 GitHub CLI를 선택한 경우 gh를 설치하고 gh auth login으로 로그인해야 합니다. PR 생성과 커밋 전송은 여러분이 요청한 경우에 진행하며, 전송할 내용을 확인한 다음 실행합니다.
main과 master
저장소에는 main과 master라는 이름이 쓰입니다. GitHub는 보통 main을 제안하지만, 로컬에서 Git을 초기화할 때는 Git 버전과 init.defaultBranch 설정에 따라 이름이 정해집니다. 프로젝트에서 실제 브랜치 이름을 확인하세요.
두 이름 모두 특별할 것 없는 일반 브랜치입니다. 예시의 명령어를 사용할 때는 여러분 저장소의 실제 브랜치 이름에 맞추세요.
Claude Code와 함께 사용할 때
이제 Git의 기본 개념을 알았으니 Claude Code가 하는 작업도 더 쉽게 이해할 수 있습니다. Claude Code가 Git으로 처리하는 일과 확인할 점을 살펴보세요.
git add,git commit,git push같은 명령어를 대신 실행합니다. IDE 버튼 뒤에서 실행되는 바로 그 명령어입니다.- 파일을 추적하도록 추가하자고 제안합니다(
git add). 해당 파일을 이력에 남길지는 여러분이 결정합니다. - 메시지를 작성해 커밋을 제안합니다. 어떤 내용을 기록할지 읽고 승인하거나 수정하세요.
- GitHub CLI를 통해 pull request(PR, 브랜치를 기본 브랜치에 병합해 달라는 제안)를 만들고 댓글을 달거나 검사 상태를 확인할 수 있습니다.
승인하기 전에 어떤 파일과 변경 사항이 커밋에 포함되는지 확인하세요. Claude Code는 IDE처럼 diff로 내용을 보여 줍니다. 이것이 여러분이 직접 확인할 지점입니다. 프로젝트 이력과 서버에 무엇이 올라가는지 항상 파악할 수 있습니다.
GO TO FULL VERSION