‘최종_진짜최종.docx’에서 벗어나는 첫걸음. Git이 왜 필요한지, Git과 GitHub가 어떻게 다른지, 그리고 시리즈 전체의 뼈대가 되는 ‘네 공간(작업 폴더·스테이징·로컬 저장소·원격 저장소)과 네 동작(add·commit·push·pull)’ 지도를 게임 세이브 포인트 비유로 풀어냅니다. macOS·Windows 설치, 처음 한 번 하는 이름·이메일 설정, cafe-menu 폴더에 git init까지 직접 따라 합니다.
회사 공유 폴더를 열어 보면 이런 파일들이 흔히 보입니다.
메뉴판_기획안.docx메뉴판_기획안_수정.docx메뉴판_기획안_최종.docx메뉴판_기획안_최종_진짜최종.docx메뉴판_기획안_최종_진짜최종(도윤수정).docx어느 게 진짜 최신인지, 최종과 진짜최종 사이에 무엇이 바뀌었는지, 도윤이 고친 부분이 내 수정과 합쳐졌는지 아무도 확신하지 못합니다. 결국 파일을 하나씩 열어 눈으로 비교하고, 가끔은 누군가의 수정이 조용히 사라집니다.
Git(깃) 은 바로 이 문제를 풀려고 만든 도구입니다. 파일 이름에 날짜와 ‘최종’을 붙이는 대신, 파일은 하나만 두고 “언제, 누가, 무엇을, 왜 바꿨는지”를 기록으로 쌓아 둡니다. 필요하면 어느 시점으로든 돌아갈 수 있고, 여러 사람이 동시에 고친 내용을 합칠 수도 있습니다.
그런데 Git은 “어렵다”는 평판이 있습니다. 명령어가 수십 개이고, 인터넷 설명은 저마다 다른 단어를 쓰고, 한 번 꼬이면 어디서부터 풀어야 할지 막막합니다. 이 시리즈는 그 두려움을 줄이는 데 집중합니다. 비밀은 간단합니다. 네 개의 공간과 네 개의 동작, 이 지도 하나만 머릿속에 있으면 나머지 명령은 모두 이 지도 위의 어딘가에 붙습니다.
이번 1편에서는 명령을 많이 치지 않습니다. 대신 지도를 그리고, Git을 설치하고, 첫 저장소를 만듭니다. 2편부터는 이 지도 위를 실제로 걸어 다닙니다.
이 시리즈에는 두 사람이 함께 등장합니다. 동네 카페 웹사이트를 기획하는 민지는 Git을 처음 배웁니다. 함께 작업하는 개발자 도윤은 민지가 막힐 때마다 옆에서 도와줍니다. 두 사람이 만드는 예제 프로젝트는 cafe-menu라는 폴더로, 1편에서 만들어 7편까지 같은 저장소를 계속 키워 갑니다.
Git은 “개발자들이 협업할 때 쓰는 도구”로 알려져 있지만, 사실 혼자 일할 때도 충분히 쓸모가 있습니다. 두 상황을 나눠 보겠습니다.
민지가 혼자서 카페 메뉴판 문서를 다듬는다고 해 봅시다. 어제는 가격표를 표로 바꿨고, 오늘은 문장을 전부 다시 썼습니다. 그런데 오후에 사장님이 “어제 문장이 더 좋던데요”라고 합니다. Git이 없다면 어제 파일을 따로 복사해 두지 않은 이상 되살릴 방법이 없습니다.
Git이 있으면 이야기가 달라집니다.
이번에는 민지와 도윤이 같은 웹사이트를 함께 만든다고 해 봅시다. 민지는 메뉴 문구를, 도윤은 페이지 디자인을 고칩니다. 파일을 메신저로 주고받으면 금방 이런 일이 생깁니다.
Git은 텍스트 파일에서 가장 강력합니다. 줄 단위로 비교하고 합치기 때문입니다. 그래서 프로그램 코드뿐 아니라 마크다운 문서(.md), 웹페이지(.html), 설정 파일, 논문 원고(LaTeX), 데이터 정의서처럼 텍스트로 된 모든 것에 잘 맞습니다. 이 시리즈의 예제에서도 menu.md 같은 문서 파일을 많이 다룹니다.
반면 .docx, .pptx, 포토샵 파일 같은 바이너리 파일(사람이 읽을 수 없는 형식)도 Git에 넣을 수는 있지만, “몇 번째 줄이 바뀌었다”를 보여 주지 못하고 자동으로 합치지도 못합니다. 기록과 되돌리기는 되지만, 협업의 장점은 줄어듭니다. 이 점만 기억해 두면 됩니다.
처음 배우는 분이 가장 많이 헷갈리는 부분입니다. 이름이 비슷해서 같은 것으로 생각하기 쉽지만, 둘은 전혀 다른 물건입니다.
비유하자면 Git은 사진기, GitHub는 사진을 올려 두는 클라우드 앨범입니다. 사진기만으로도 사진은 찍고 볼 수 있습니다. 앨범 서비스가 있으면 백업이 되고, 가족과 함께 볼 수 있습니다. 앨범 서비스는 여러 회사가 만들듯, GitHub 말고도 GitLab, Bitbucket 같은 비슷한 서비스가 있습니다. 어느 곳을 쓰든 내 컴퓨터에서 Git을 쓰는 방법은 똑같습니다.
| 구분 | Git | GitHub |
|---|---|---|
| 정체 | 프로그램 (내 컴퓨터에 설치) | 인터넷 서비스 (웹사이트) |
| 하는 일 | 변경 기록, 되돌리기, 브랜치, 합치기 | 저장소 보관·공유, 웹에서 보기, Pull Request, 이슈 |
| 인터넷 | 없어도 대부분 동작 | 필요 |
| 만든 곳 | 리누스 토르발스(2005), 오픈소스 커뮤니티가 유지 | GitHub사(2008년 서비스 시작), 현재 마이크로소프트 소유 |
| 대안 | — | GitLab, Bitbucket 등 |
| 이 시리즈에서 | 1·2·4·5편의 중심 | 3·6편에서 본격 등장 |
그러니 “GitHub에 가입해야 Git을 쓸 수 있나요?”의 답은 아니요입니다. 1편과 2편은 GitHub 계정 없이 내 컴퓨터만으로 따라 할 수 있습니다. GitHub 계정은 3편에서 원격 저장소를 만들 때 필요합니다.
아래 문장들이 Git 이야기인지 GitHub 이야기인지 직접 골라 보세요.
Git을 이해하는 가장 쉬운 비유는 게임의 세이브 포인트입니다.
어려운 보스 앞에서 게임을 저장해 두면, 져도 그 지점에서 다시 시작할 수 있습니다. 저장 슬롯이 여러 개라면 “보스 앞”, “상점 들르기 전”처럼 이름을 붙여 원하는 지점으로 골라 돌아갈 수도 있습니다.
Git의 커밋(commit) 이 바로 이 세이브입니다. 커밋 하나하나가 “그 순간 프로젝트 전체의 모습”을 사진처럼 찍어 두는 기록이고, 각 커밋에는 메시지(이름표)가 붙습니다.
| 게임 | Git | 설명 |
|---|---|---|
| 게임 진행 | 파일 수정 | 평소처럼 편집기에서 파일을 고치고 저장합니다 |
| 세이브할 항목 고르기 | git add | 이번 기록에 무엇을 담을지 고릅니다 |
| 세이브하기 | git commit | 이름표(메시지)를 붙여 기록을 남깁니다 |
| 세이브 슬롯 목록 | git log | 지금까지 남긴 기록을 봅니다 |
| 세이브 불러오기 | git restore, git revert 등 | 과거 시점으로 되돌립니다 (5편) |
| 클라우드 세이브 업로드 | git push | 내 기록을 서버(원격 저장소)에 올립니다 |
| 다른 기기에서 클라우드 세이브 받기 | git pull | 서버에 있는 새 기록을 받아옵니다 |
게임 비유와 다른 점이 하나 있습니다. 게임의 세이브는 보통 덮어쓰기지만, Git의 커밋은 계속 쌓입니다. 새 커밋을 만든다고 이전 커밋이 사라지지 않습니다. 그래서 “세 번 전 기록”으로도, “지난주 화요일 기록”으로도 돌아갈 수 있습니다.
그리고 또 하나. 자동 저장이 아니라는 점입니다. 편집기에서 Ctrl+S(맥은 Cmd+S)로 파일을 저장하는 것과 Git 커밋은 다릅니다. 파일 저장은 “지금 내용을 디스크에 쓴다”이고, 커밋은 “이 순간을 기록으로 남긴다”입니다. 파일을 백 번 저장해도 커밋하지 않으면 Git 기록에는 아무것도 남지 않습니다. 반대로 말하면, 언제 세이브할지는 내가 정합니다. 의미 있는 작업 한 덩어리가 끝났을 때 커밋하면 됩니다(좋은 커밋 단위는 2편에서 다룹니다).
이제 이 시리즈에서 가장 중요한 그림입니다. 앞으로 나올 거의 모든 명령은 이 지도 위에서 “파일(또는 기록)을 어느 칸에서 어느 칸으로 옮기는가”로 설명됩니다. 이 절만큼은 천천히 읽어 주세요.
addcommitpushpull: ④ 원격 저장소의 새 기록을 ③ 로컬 저장소로 받아오고, ① 작업 폴더의 파일까지 최신으로 바꿉니다왼쪽 세 칸(①②③)은 모두 내 컴퓨터 안에 있고, 오른쪽 한 칸(④)만 인터넷 너머에 있습니다. 이 경계가 중요합니다. 하나씩 살펴보겠습니다.
평소에 보는 그 폴더입니다. Finder나 파일 탐색기에서 열면 보이는 index.html, menu.md 같은 파일들이 여기에 있습니다. 편집기로 파일을 고치고 저장하면 바뀌는 곳이 이 칸입니다. Git 입장에서는 “아직 기록하지 않은 변경이 있을 수 있는, 자유로운 작업대”입니다.
다음 커밋에 담을 변경을 올려 두는 대기 공간입니다. 인덱스(index)라고도 부릅니다. 택배를 보내기 전에 상자에 물건을 담는 단계로 생각하면 좋습니다. 상자에 담은 물건만 발송되듯, 스테이징에 올린 변경만 커밋됩니다.
처음 배우는 분들은 “왜 바로 커밋하지 않고 한 단계를 더 거치지?”라고 묻습니다. 이유는 골라 담기 때문입니다. 민지가 menu.md에서는 가격을 고치고, index.html에서는 실험 삼아 색을 바꿔 봤다고 합시다. 가격 수정만 먼저 기록하고 싶다면 menu.md만 스테이징에 올려 커밋하면 됩니다. 색 실험은 작업 폴더에 그대로 남아 있습니다. 덕분에 커밋 하나하나가 “한 가지 일”을 담는 깔끔한 기록이 됩니다.
커밋들이 차곡차곡 쌓이는 내 컴퓨터 안의 기록 보관소입니다. 실제로는 프로젝트 폴더 안의 숨겨진 .git 폴더가 이 역할을 합니다(8절에서 직접 봅니다). 로컬(local)은 “내 컴퓨터에 있는”이라는 뜻이고, 저장소(repository, 줄여서 repo)는 “기록을 담는 창고”라는 뜻입니다.
여기까지는 인터넷이 전혀 필요 없습니다. 비행기 안에서도 커밋을 만들고, 기록을 보고, 과거로 되돌릴 수 있습니다. 대신 여기 있는 기록은 나만 봅니다. 도윤은 민지의 커밋을 볼 수 없고, 노트북이 고장 나면 함께 사라집니다.
인터넷 어딘가(보통 GitHub)에 있는 공유용 저장소입니다. 팀원 모두가 이곳을 기준으로 기록을 주고받습니다. 원격(remote)은 “멀리 떨어진”이라는 뜻입니다. 로컬 저장소의 복사본이 서버에 하나 더 있는 셈이라 백업 역할도 합니다.
이 네 동작의 방향을 기억하는 요령이 있습니다.
아래 시뮬레이터에서 버튼을 눌러 menu.md를 네 칸으로 옮겨 보세요. 추천 순서는 이렇습니다.
지금 따라 칠 필요는 없습니다. 2편과 3편에서 하나씩 천천히 할 내용을, 한 사이클만 미리 보여 드립니다. 아래는 실제로 Git 2.55에서 실행한 결과입니다. 민지가 README.md 파일 하나를 만들고 네 동작을 거치는 과정입니다.
먼저 파일을 만든 직후, ① 작업 폴더에만 변경이 있는 상태입니다. git status는 “지금 네 공간이 어떤 상태인지” 알려 주는 명령입니다.
git status
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
README.md
nothing added to commit but untracked files present (use "git add" to track)
Untracked files는 “Git이 아직 한 번도 기록한 적 없는 새 파일”이라는 뜻입니다. git add로 ② 스테이징에 올리면 표시가 바뀝니다.
git add README.md
git status
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: README.md
Changes to be committed, 즉 “다음 커밋에 들어갈 변경”이 생겼습니다. 이제 커밋으로 ③ 로컬 저장소에 기록합니다.
git commit -m "README 추가"
[main (root-commit) 4622ad0] README 추가
1 file changed, 1 insertion(+)
create mode 100644 README.md
4622ad0이 이 세이브 포인트의 이름표(커밋 해시)입니다. 여러분이 실행하면 다른 값이 나옵니다. 마지막으로 ④ 원격 저장소로 push 합니다(원격 연결 방법은 3편에서 다룹니다).
git push -u origin main
To ../remote.git
* [new branch] main -> main
branch 'main' set up to track 'origin/main'.
이번 미리보기에서는 GitHub 대신 내 컴퓨터 안에 가짜 원격 저장소(../remote.git)를 만들어 썼습니다. GitHub를 쓰면 이 자리에 https://github.com/... 주소가 나옵니다. 그 뒤 도윤이 자기 컴퓨터에서 menu.md를 추가해 push 했고, 민지가 pull 하면 이렇게 받아집니다.
git pull
From ../remote
4622ad0..648def3 main -> origin/main
Updating 4622ad0..648def3
Fast-forward
menu.md | 1 +
1 file changed, 1 insertion(+)
create mode 100644 menu.md
도윤의 커밋(648def3)이 민지의 로컬 저장소로 들어오고, 민지의 작업 폴더에 menu.md 파일이 생겼습니다. 명령 네 개가 지도 위의 화살표 네 개와 정확히 대응한다는 것만 확인하면 충분합니다.
지도를 제대로 익혔는지 상황 퀴즈로 점검해 보세요.
이제 실제로 내 컴퓨터에 Git을 설치할 차례입니다. 먼저 이미 설치되어 있는지 확인합니다. 맥에서는 터미널 앱(Spotlight에서 Cmd+Space 후 “터미널” 입력)을 열고 아래 명령을 붙여 넣습니다.
git --version
버전 번호가 나오면 이미 설치된 것입니다. 이 글을 쓰는 맥에서는 두 가지 Git이 있어서, 경로에 따라 이렇게 나옵니다.
git version 2.55.0
git version 2.50.1 (Apple Git-155)
위쪽은 Homebrew로 설치한 최신 Git, 아래쪽은 애플이 개발자 도구와 함께 제공하는 Git입니다. 둘 다 이 시리즈를 따라오기에 충분합니다.
맥에 Git이 없는 상태에서 git --version을 치면, “명령줄 개발자 도구를 설치하겠습니까?”라는 창이 뜹니다. 설치를 누르면 Git을 포함한 개발 도구가 설치됩니다. 창이 뜨지 않으면 직접 요청할 수 있습니다.
xcode-select --install
용량이 큰 Xcode 앱 전체가 아니라 명령줄 도구만 설치되므로 부담이 적습니다. 설치가 끝나면 터미널을 새로 열고 git --version으로 다시 확인합니다.
맥용 패키지 관리자인 Homebrew를 쓰고 있다면 한 줄이면 됩니다. 애플이 제공하는 Git보다 새 버전을 쓸 수 있고, 업데이트도 brew upgrade git으로 간단합니다.
brew install git
설치 후 어떤 Git이 쓰이는지 확인하려면 아래 명령을 씁니다. Apple Silicon 맥에서는 보통 /opt/homebrew/bin/git이 나오면 Homebrew 쪽 Git이 쓰이고 있다는 뜻입니다.
which git
which git에 나오는 쪽을 씁니다.
윈도우에는 Git이 기본으로 들어 있지 않습니다. Git for Windows를 설치하면 Git과 함께 Git Bash라는 터미널 프로그램이 들어옵니다. 이 시리즈의 명령은 Git Bash에서 그대로 따라 할 수 있습니다(PowerShell이나 명령 프롬프트에서도 git 명령 자체는 똑같이 동작합니다).
| 설치 화면 | 추천 선택 | 이유 |
|---|---|---|
| 기본 편집기 선택 | 메모장(Notepad) 또는 VS Code | 기본값은 Vim입니다. Vim에 익숙하지 않다면 커밋 메시지 입력 화면에서 빠져나오는 법부터 막힙니다. |
| 새 저장소의 기본 브랜치 이름 | Override를 고르고 main | 요즘 표준 이름입니다. 여기서 안 해도 7절의 설정 명령으로 똑같이 맞출 수 있습니다. |
| 그 밖의 화면 | 기본값 | 처음에는 바꿀 이유가 없습니다. |
윈도우 11에는 명령줄 패키지 관리자 winget이 기본으로 들어 있습니다. PowerShell이나 Windows 터미널을 열고 아래 명령을 입력하면 같은 Git for Windows가 설치됩니다.
winget install --id Git.Git -e --source winget
설치가 끝나면 시작 메뉴에서 Git Bash를 열고(또는 새 PowerShell 창에서) 버전을 확인합니다.
git --version
git version 2.xx.x.windows.x 형식의 결과가 나오면 성공입니다. 이미 열려 있던 터미널 창에서는 새로 설치한 git을 찾지 못할 수 있으니, 설치 후에는 터미널을 새로 여세요.
Git은 커밋마다 “누가 만들었는지” 를 함께 기록합니다. 그래서 설치 직후 딱 한 번, 내 이름과 이메일을 알려 줘야 합니다. 민지라면 이렇게 입력합니다(여러분의 이름과 이메일로 바꿔 넣으세요).
git config --global user.name "민지"
git config --global user.email "minji@example.com"
그리고 새 저장소의 기본 브랜치 이름을 main으로 정합니다. 브랜치는 4편에서 자세히 다루니, 지금은 “기록이 쌓이는 줄기의 이름”이라고만 알아 두면 됩니다.
git config --global init.defaultBranch main
--global은 “이 컴퓨터의 모든 저장소에 적용”이라는 뜻입니다. 설정이 잘 들어갔는지 확인해 봅시다.
git config --global --list
user.name=민지
user.email=minji@example.com
init.defaultbranch=main
이 설정은 홈 폴더의 .gitconfig라는 텍스트 파일에 저장됩니다. 열어 보면 방금 넣은 값이 그대로 들어 있습니다.
cat ~/.gitconfig
[user]
name = 민지
email = minji@example.com
[init]
defaultBranch = main
이름·이메일을 설정하지 않으면, Git은 컴퓨터의 사용자 이름과 호스트 이름으로 적당히 만들어 커밋에 넣고 이런 경고를 띄웁니다(실제 출력에서 사용자·컴퓨터 이름만 바꿨습니다).
[master (root-commit) 69bbfd7] 첫 커밋
Committer: minji <minji@Minjiui-MacBookAir.local>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
이렇게 남은 커밋은 GitHub에 올렸을 때 내 계정과 연결되지 않습니다. 환경에 따라서는 아예 Author identity unknown ... Please tell me who you are.라는 오류와 함께 커밋이 거부되기도 합니다. 어느 쪽이든 위의 두 줄로 설정하면 해결됩니다.
기본 브랜치를 설정하지 않으면, Git 2.55는 여전히 master라는 이름으로 첫 브랜치를 만들고 긴 안내문을 보여 줍니다.
hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0. To configure the initial branch name
hint: to use in all of your new repositories, which will suppress this warning,
hint: call:
hint:
hint: git config --global init.defaultBranch <name>
안내문에 적힌 대로 Git 3.0부터는 기본값이 main으로 바뀔 예정이고, GitHub도 새 저장소의 기본 브랜치를 main으로 만듭니다. 미리 main으로 맞춰 두면 3편에서 GitHub와 연결할 때 이름이 어긋나는 일이 없습니다.
noreply 주소를 쓸 수도 있습니다(GitHub 이메일 설정 화면에서 확인).
회사 저장소에서는 회사 이메일, 개인 프로젝트에서는 개인 이메일을 쓰고 싶을 수도 있습니다. 그럴 때는 해당 저장소 폴더 안에서 --global 없이 설정하면 그 저장소에만 적용됩니다.
git config user.email "minji@company.example"
이제 시리즈 내내 쓸 예제 프로젝트를 만듭니다. 홈 폴더 아래에 cafe-menu 폴더를 만들고 그 안으로 들어갑니다.
cd ~
mkdir cafe-menu
cd cafe-menu
cd는 폴더 이동(change directory), mkdir은 폴더 만들기(make directory)입니다. ~는 내 홈 폴더를 뜻합니다(Git Bash에서도 똑같이 동작합니다). 이제 이 폴더를 Git 저장소로 만듭니다.
git init
Initialized empty Git repository in /Users/minji/cafe-menu/.git/
“비어 있는 Git 저장소를 .git 안에 만들었다”는 뜻입니다. 이 한 줄로 평범한 폴더가 ① 작업 폴더가 되고, 그 안에 ②③을 담당하는 .git 폴더가 생겼습니다. 지금 상태를 확인해 봅시다.
git status
On branch main
No commits yet
nothing to commit (create/copy files and use "git add" to track)
브랜치 이름이 main으로 나오면 7절의 설정이 잘 먹힌 것입니다. 아직 커밋도, 파일도 없으니 “파일을 만들고 git add를 쓰세요”라고 안내합니다.
…/.git/ 안의 빈 깃 저장소를 다시 초기화했습니다라고 “다시”가 붙어 나오는데, Git 2.55.0에서 직접 확인해 보니 번역 문구의 문제일 뿐 새로 잘 만들어진 것입니다. 이미 있던 저장소에서 다시 실행하면 기존 깃 저장소를 다시 초기화했습니다로 “기존”이 붙습니다. 이 시리즈는 검색하기 쉽도록 영어 출력으로 보여 드립니다.
ls로 폴더를 보면 아무것도 없는 것 같지만, 숨김 파일까지 보여 주는 -a 옵션을 붙이면 .git이 나타납니다.
ls -a
.
..
.git
이름이 점(.)으로 시작하는 파일과 폴더는 맥·리눅스에서 숨김 항목으로 취급되고, 윈도우의 Git for Windows도 이 폴더를 숨김 속성으로 만듭니다. Finder에서는 Cmd+Shift+.(마침표)를 누르면 숨김 항목이 보이고, 윈도우 탐색기에서는 보기 → 표시 → 숨긴 항목을 켜면 보입니다. 안을 들여다보면 이런 것들이 들어 있습니다.
ls -F .git
config
description
HEAD
hooks/
info/
objects/
refs/
커밋이 쌓이는 곳(objects/), 브랜치 이름표가 있는 곳(refs/), 지금 어느 브랜치에 있는지 적어 두는 파일(HEAD), 이 저장소만의 설정(config) 등입니다. 각각이 무슨 일을 하는지는 몰라도 됩니다. 다만 이것만은 꼭 기억하세요.
git init 하지 않기. cd ~만 하고 mkdir, cd cafe-menu를 빠뜨린 채 git init을 치면, 홈 폴더 전체가 저장소가 됩니다. 그러면 모든 폴더에서 이상한 git status 결과가 나옵니다. 실수로 그랬다면, 그 홈 폴더의 .git 폴더 하나만 지우면 됩니다(이 경우는 기록할 게 없던 잘못 만든 저장소이므로 지워도 괜찮습니다).cafe-menu 안의 하위 폴더에서 다시 git init 할 필요는 없습니다. 저장소 하나가 그 아래 모든 하위 폴더를 관리합니다. 지금 있는 곳이 어느 저장소에 속해 있는지 궁금하면 아래 명령으로 저장소의 맨 위 폴더를 확인할 수 있습니다.git rev-parse --show-toplevel
저장소 밖이라면 fatal: not a git repository 오류가 나옵니다. 이 오류 메시지는 앞으로도 자주 보게 될 텐데, 대부분 “저장소 폴더 안으로 cd 하지 않고 git 명령을 쳤다”는 뜻입니다.
이제 cafe-menu는 Git 저장소가 되었습니다. 비어 있을 뿐입니다. 2편에서 여기에 index.html, menu.md, README.md를 만들고 첫 커밋을 남깁니다.
Claude Code 같은 AI 코딩 에이전트도 특별한 길로 다니지 않습니다. 에이전트는 여러분의 프로젝트 폴더에서 여러분과 똑같은 git 명령을 실행합니다. 그러니 네 공간 지도는 에이전트가 하는 일을 이해하는 지도이기도 합니다.
에이전트에게 일을 맡길 때 1편 수준에서 챙길 것은 세 가지입니다.
git init이 된 폴더(또는 GitHub에서 받은 저장소)라면, 에이전트가 무엇을 바꿨는지 Git으로 언제든 확인하고 되돌릴 수 있습니다. Git이 에이전트의 안전망이 됩니다.git status로 직접 확인해 보세요.에이전트가 브랜치를 나누고, Pull Request를 열고, 여러 작업을 동시에 진행하는 장면은 7편에서 자세히 다룹니다.
Q1. Git을 쓰려면 GitHub 가입이 필수인가요?
아닙니다. Git은 내 컴퓨터의 프로그램이라 GitHub 없이도 커밋·기록 보기·되돌리기가 모두 됩니다. GitHub는 기록을 다른 사람과 공유하거나 서버에 백업하고 싶을 때(3편) 필요합니다.
Q2. 커밋은 자주 해야 하나요, 가끔 해야 하나요?
“의미 있는 한 덩어리의 작업이 끝났을 때”가 기준입니다. 너무 드물면 되돌릴 지점이 부족하고, 너무 잘게 쪼개면 기록을 읽기 어렵습니다. “메뉴 가격 수정”, “영업시간 안내 추가”처럼 한 문장으로 설명할 수 있는 단위가 좋습니다. 2편에서 좋은 커밋 단위와 메시지 쓰는 법을 다룹니다.
Q3. 스테이징 단계가 꼭 필요한가요? 그냥 바로 커밋하면 안 되나요?
스테이징이 있어서 “이번 기록에 넣을 것만 골라 담기”가 가능합니다. 여러 파일을 고쳤어도 관련 있는 것끼리 나눠 커밋할 수 있습니다. 익숙해지면 추적 중인 파일을 한 번에 담아 커밋하는 단축 방법도 있지만, 처음에는 add와 commit을 따로 하면서 지도를 몸에 익히는 편이 좋습니다.
Q4. git init을 잘못된 폴더에서 했어요. 어떻게 되돌리나요?
그 폴더 안에 생긴 .git 폴더만 지우면 원래 평범한 폴더로 돌아갑니다. 작업 파일은 건드리지 않습니다. 단, 이미 그 저장소에서 커밋을 쌓아 왔다면 기록이 모두 사라지니, 정말 잘못 만든 저장소인지 git log로 먼저 확인하세요.
Q5. 한국어 환경에서 git init을 했더니 “다시 초기화했습니다”라고 나와요. 원래 있던 걸 덮어쓴 건가요?
새로 만든 것이 맞습니다. Git 2.55.0의 한국어 번역에서 새 저장소 메시지에도 “다시”가 붙어 나옵니다. 정말 기존 저장소를 다시 초기화한 경우에는 “기존 깃 저장소를”이라고 나오니 그것으로 구분하면 됩니다. 기존 저장소에서 git init을 다시 해도 기록은 지워지지 않습니다.
Q6. Git의 역사나 내부 구조(커밋이 어떻게 저장되는지)가 더 궁금해요.
이 시리즈는 “쓸 수 있게 되는 것”에 집중합니다. 역사와 내부 구조까지 궁금하다면 Git 완전 정복 — 버전 관리 가이드를 함께 읽어 보세요.
| 개념·명령 | 한 줄 뜻 | 지도에서의 위치 |
|---|---|---|
| Git | 내 컴퓨터에서 변경을 기록하는 프로그램 | ①②③ 전체를 관리 |
| GitHub | 저장소를 맡아 주고 함께 보게 해 주는 서비스 | ④ 원격 저장소가 사는 곳 |
| 커밋(commit) | 메시지가 붙은 세이브 포인트 | ③에 쌓임 |
git add | 다음 커밋에 담을 변경 고르기 | ① → ② |
git commit | 담은 변경을 기록으로 남기기 | ② → ③ |
git push | 내 커밋을 서버로 올리기 | ③ → ④ |
git pull | 서버의 새 커밋을 받아 내 파일까지 최신으로 | ④ → ③ → ① |
git --version | 설치 확인 | — |
git config --global user.name "이름" | 커밋 작성자 이름 설정 (처음 한 번) | — |
git config --global user.email "메일" | 커밋 작성자 이메일 설정 (처음 한 번) | — |
git config --global init.defaultBranch main | 새 저장소의 기본 브랜치를 main으로 | — |
git init | 지금 폴더를 Git 저장소로 만들기 | ①을 만들고 .git(②③) 생성 |
git status | 네 공간의 현재 상태 보기 | ①②③ 비교 |
.git 폴더 | 기록 전체가 들어 있는 숨김 폴더 | 절대 지우지 않기 |
지도는 그렸고, 저장소도 만들었습니다. 이제 걸어 볼 차례입니다. 2편에서는 민지가 텅 빈 cafe-menu에 index.html, menu.md, README.md를 만들고 첫 커밋을 남깁니다. 지도의 왼쪽 세 칸(① 작업 폴더 → ② 스테이징 → ③ 로컬 저장소)을 자유롭게 오가는 데 필요한 명령을 모두 다룹니다.
git status로 지금 상태 읽기, git diff로 무엇이 바뀌었는지 보기git add로 골라 담고 git commit으로 기록하기git log로 지난 세이브 포인트 둘러보기.gitignore인터넷도 GitHub 계정도 아직 필요 없습니다. 터미널과 cafe-menu 폴더만 준비해 두세요.
RELATED
