Git 기초 매뉴얼

내 컴퓨터에서 동작하는 로컬 버전 관리 — 코드의 변경 이력을 기록하고 골라 담는 핵심 명령 | 공식 문서: git-scm.com/docs

대상 버전git 2.5x (2.50.1 기준)

참조 문서 URLgit-scm.com/docs · Pro Git 책(한국어)

문서 수집일2026-06-16

버전 확인 방법git --version 으로 설치된 버전을 확인한다.

개정 시 확인 사항명령·옵션 변경 여부는 git-scm.com에서 다시 확인한다.

명령어 트리 (Command Tree)

이 섹션은 네트워크 없이 내 컴퓨터 안에서만 동작하는 Git을 다룬다. 파일을 고치고 → git add로 담을 것을 고르고 → git commit으로 하나의 버전(스냅샷)으로 확정하는 흐름이 전부다. 이 add → commit 리듬이 Git 사용의 90%다.

git  (내 컴퓨터의 로컬 도구 — 인터넷 불필요)
├── git config                    사용자 이름·이메일 등 환경 설정 (맨 처음 1회)
│
├── [저장소 시작]
│   └── git init                  현재 폴더를 새 Git 저장소로 만들기
│
├── [변경 기록 3단계]
│   ├── git status                현재 상태 확인 (무엇이 바뀌었나)
│   ├── git add <file>           변경을 스테이징 영역에 올리기 (커밋 후보 선택)
│   └── git commit -m "메시지"    스테이징된 변경을 하나의 버전으로 확정·저장
│
├── [기록 살펴보기]
│   ├── git diff                  아직 스테이징 안 된 변경 내용 보기
│   ├── git diff --staged         스테이징된(곧 커밋될) 변경 내용 보기
│   └── git log                   커밋 이력(과거 버전 목록) 보기
│
└── [무시 목록]
    └── .gitignore                버전 관리에서 제외할 파일 패턴 (명령이 아닌 파일)

💡 흐름 한 줄 요약: git init으로 시작 → 파일 수정 → git add로 담을 것을 고르고 → git commit으로 저장. git status는 막힐 때마다 길을 알려 주는 나침반이다.

🔗 다음 단계 안내: 만든 저장소를 인터넷에 올려 공유·협업하는 clone·remote·push·pull은 GitHub 매뉴얼에서, commit --amend·reset·revert·restore 같은 되돌리기는 되돌리기·복구 매뉴얼에서 다룬다.

1. 버전 관리란? (Version Control)

💡 배경 개념: 버전 관리가 뭔가요?

버전 관리는 '파일이 시간에 따라 어떻게 바뀌었는지'를 기록해 두었다가, 원하는 시점으로 되돌아갈 수 있게 해 주는 시스템입니다. 비유하자면 게임의 세이브 포인트와 같습니다. 위험한 구간 앞에서 저장해 두면, 실패해도 그 지점부터 다시 시작할 수 있습니다. 코드도 마찬가지로, 잘 돌아가던 시점에 '저장(커밋)'해 두면 나중에 무언가 망가져도 그 시점으로 안전하게 돌아갈 수 있습니다.

Git은 그 세이브 기능을 코드에 전문적으로 적용한 도구입니다. 보고서_최종.docx, 보고서_최종_진짜최종.docx처럼 파일 이름을 늘려 가며 백업하던 방식을, 하나의 폴더 안에서 깔끔한 '버전 타임라인'으로 대체합니다. 누가·언제·무엇을·왜 바꿨는지가 모두 기록으로 남습니다.

`git` — 바이브 코딩에서 버전 관리가 특히 중요한 이유

AI 도구는 한 번에 여러 파일을, 또는 한 파일 안에서도 많은 줄을 한꺼번에 바꿉니다. 그 변경이 잘 동작하는지 확신하기 전에 커밋해 두지 않으면, 다음 지시로 코드가 망가졌을 때 되돌릴 기준점이 없습니다. 그래서 'AI가 만든 변경을 작은 단위로 자주 커밋하는' 습관이 바이브 코딩의 안전벨트입니다.

되돌리기: 잘못 고쳤을 때 마지막으로 정상이던 버전으로 복구할 수 있습니다.
이력 추적: 각 변경에 메시지를 붙여 두어 "이 코드를 왜 이렇게 짰지?"의 답을 남깁니다.
안전한 실험: 커밋해 둔 시점이 있으면, 그 위에서 마음껏 시도하고 실패하면 되돌리면 됩니다.
협업의 기반: 여러 사람이 같은 코드를 동시에 고치고 합칠 수 있습니다 (GitHub와 함께).

📌 Git과 GitHub는 다릅니다. Git은 내 컴퓨터에서 도는 '버전 관리 프로그램'이고(인터넷이 없어도 동작), GitHub는 그 Git 저장소를 인터넷에 올려 공유·협업하는 '웹 서비스'입니다. 이 문서는 먼저 내 컴퓨터 안의 로컬 Git만 다룹니다. GitHub로 올리고 받는 일은 GitHub 매뉴얼에서 배웁니다.

2. Git의 세 공간 (Working Tree · Staging · Repository)

Git을 처음 배울 때 가장 헷갈리는 부분이 바로 이 '세 개의 공간'입니다. 이 구조만 이해하면 add와 commit이 왜 나뉘어 있는지 단번에 이해됩니다.

작업 폴더 (Working Tree)          에디터로 직접 편집하는 그 폴더
   │
   │  git add                     "이번 커밋에 담을 변경"만 골라 올림
   ▼
스테이징 영역 (Staging / Index)   커밋 대기 공간 — 담아 둔 변경
   │
   │  git commit                  담긴 변경을 하나의 버전(스냅샷)으로 확정
   ▼
저장소 (Repository)               .git 안에 버전이 영구 보존 — 이력이 여기 쌓임

공간	한 줄 설명	비유	여기로 보내는 명령
작업 폴더 (Working Tree)	지금 내가 파일을 실제로 편집하는 공간. 에디터로 보고 있는 그 폴더입니다.	작업 책상 위	(파일 편집)
스테이징 영역 (Staging Area / Index)	"이번 커밋에 담을 변경"을 골라 모아 두는 대기 공간.	택배 상자에 담기	`git add`
저장소 (Repository)	커밋으로 영구 보존된 버전들의 창고. 이력이 여기 쌓입니다.	발송 완료·보관함	`git commit`

💡 왜 add와 commit이 따로 있나요? 한 번에 수정한 여러 변경 중 관련 있는 것만 골라 하나의 의미 있는 버전으로 묶기 위해서입니다. 예를 들어 AI가 '로그인 기능'과 '오타 수정'을 같이 바꿔 놨어도, add로 로그인 부분만 골라 따로 커밋하면 이력이 깔끔해집니다. 이 '골라 담기'가 가능한 이유가 바로 스테이징 영역입니다.

파일의 상태 흐름

같은 파일이라도 git status에서는 어느 공간에 있느냐에 따라 다르게 표시됩니다. 아래 그림이 그 흐름입니다.

↩️ 거꾸로 되돌리는 흐름(스테이징 취소 git restore --staged, 커밋 취소 git reset 등)은 되돌리기·복구 매뉴얼에서 다룹니다.

3. 초기 설정 (config)

Git을 설치하고 처음 한 번, 커밋에 기록될 내 이름과 이메일을 설정해야 합니다. 이 정보는 모든 커밋에 '작성자'로 남으므로, 첫 커밋 전에 반드시 해 둡니다.

`git config` — 사용자 이름·이메일 등 환경 설정

--global을 붙이면 이 컴퓨터의 모든 저장소에 한 번에 적용됩니다. 보통은 이 전역 설정 한 번이면 충분합니다. 설정값은 git config --list로 언제든 확인할 수 있습니다.

git config --global user.name "Hong Gildong"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main   # 새 저장소 기본 브랜치를 main으로
git config --list                             # 현재 설정 확인

범위 플래그	적용 범위
`--global`	이 컴퓨터의 내 모든 저장소 (보통 이걸 씁니다)
`--local` (기본)	현재 저장소 하나에만
`--system`	컴퓨터의 모든 사용자

💡 나중에 GitHub에 올릴 거라면 user.email을 GitHub 계정 이메일과 맞추세요. 그래야 커밋이 내 GitHub 활동으로 연결됩니다.

4. 저장소 시작 (init)

`git init` — 현재 폴더를 Git 저장소로

현재 폴더 안에 숨김 폴더 .git을 만들어, 그 폴더를 Git이 추적하기 시작합니다. 내 컴퓨터에서 새 프로젝트를 시작할 때 한 번만 실행합니다. -b main을 붙이면 기본 브랜치 이름을 main으로 지정하며 초기화합니다.

cd ~/projects/my-app     # 관리할 폴더로 이동
git init                 # 이 폴더를 Git 저장소로 초기화
git init -b main         # 기본 브랜치 이름을 main으로 지정하며 초기화

.git 폴더가 곧 저장소의 본체입니다. 이 폴더를 지우면 모든 커밋 이력이 사라집니다. 평소엔 건드리지 마세요.

🔗 이미 GitHub 등에 있는 프로젝트를 내 컴퓨터로 통째로 받아 시작하는 git clone은 인터넷이 필요한 작업이라 이 섹션이 아니라 GitHub 매뉴얼에서 다룹니다.

5. 변경 기록하기 (add · commit)

`git add` — 변경을 스테이징에 올리기

작업 폴더의 변경 중 '이번 커밋에 담을 것'을 골라 스테이징 영역에 올립니다. 파일을 처음 추적 대상으로 등록할 때도 add를 씁니다. 핵심은 git add -p로, 한 파일 안의 변경도 hunk(덩어리) 단위로 골라 담을 수 있어 AI가 한 번에 쏟아낸 큰 변경을 의미 단위로 쪼갤 때 결정적입니다.

git add index.html          # 특정 파일 하나
git add -A                  # 전체 변경(추가·수정·삭제 모두)
git add -u                  # 추적 중인 파일의 수정·삭제만 (새 파일 제외)
git add -p                  # 한 파일 안에서도 변경 덩어리(hunk)별로 골라 담기

옵션	담는 범위
`git add <파일>`	지정한 파일/폴더의 변경
`git add -A`	저장소 전체의 추가·수정·삭제 모두
`git add -u`	이미 추적 중인 파일의 수정·삭제만 (새 파일은 빠짐)
`git add -p`	변경 덩어리(hunk)마다 담을지 대화형으로 선택

git add -A는 편하지만, 의도치 않은 파일(임시·비밀 파일)까지 담길 수 있습니다. git status로 무엇이 담겼는지 확인하는 습관을 들이세요. 아예 제외하고 싶은 파일은 .gitignore에 등록합니다.

`git commit` — 스테이징된 변경을 버전으로 확정

스테이징된 변경들을 하나의 버전(커밋·스냅샷)으로 묶어 저장소에 영구 기록합니다. -m으로 메시지를 함께 적고, -a는 이미 추적 중인 파일의 변경을 add 없이 바로 커밋합니다(새 파일은 제외). 메시지 관례는 첫 줄 50자 이내 요약 → (필요하면) 빈 줄 → 상세 설명입니다.

git commit -m "로그인 폼 유효성 검사 추가"
git commit -a -m "버튼 색상 수정"   # -a: 추적 중인 파일을 add 없이 바로 커밋
git commit                         # -m 생략 시 편집기가 열려 여러 줄 메시지 작성

📝 좋은 커밋 메시지: 현재형 동사로 무엇을·왜 바꿨는지 구체적으로. "수정함"(X) → "로그인 실패 시 에러 메시지 표시"(O). 한 커밋엔 한 가지 주제만 담으면 이력을 읽기 쉽습니다. -a는 이미 추적 중인 파일에만 적용되며, 새로 만든 파일은 먼저 git add가 필요합니다.

↩️ 방금 만든 커밋의 메시지를 고치거나 빠뜨린 파일을 끼워 넣는 git commit --amend는 '되돌리기'에 해당하므로 되돌리기·복구 매뉴얼에서 다룹니다.

6. 상태 확인 (status · diff · log)

`git status` — 지금 무슨 일이 일어났나

가장 자주 쓰는 명령입니다. HEAD·스테이징 영역(index)·작업 폴더 사이의 차이를 보여 주어, 어떤 파일이 수정·추가·삭제됐는지, 무엇이 스테이징됐는지를 구분해 알려 줍니다. 막힐 때마다 git status를 치면 다음에 뭘 해야 할지 힌트가 나옵니다.

git status            # 자세히 보기
git status -s         # 짧게 보기 (한 줄에 한 파일)

`git diff` — 무엇이 어떻게 바뀌었나

실제 코드의 변경 내용(추가된 줄·삭제된 줄)을 줄 단위로 보여 줍니다. 인자 없이 쓰면 아직 스테이징하지 않은 변경을, --staged를 붙이면 곧 커밋될 변경을 봅니다. AI가 만든 변경은 커밋 전에 diff로 눈으로 검토하는 습관이 특히 중요합니다.

명령	보여 주는 것
`git diff`	작업 폴더의 변경 중 아직 add 안 한 부분 (작업트리 vs index)
`git diff --staged`	add는 했지만 commit 안 한 부분, 곧 커밋될 내용 (별칭 `--cached`)
`git diff HEAD`	마지막 커밋 대비 모든 변경 (스테이징 포함)

`git log` — 커밋 이력 보기

지금까지 쌓인 커밋 목록을 최신순으로 보여 줍니다. 각 커밋의 고유 ID(해시), 작성자, 날짜, 메시지가 나옵니다. --oneline으로 한 줄씩 간략히 훑는 것이 가장 자주 쓰는 형태입니다.

git log                          # 전체 이력 (q 키로 빠져나옴)
git log --oneline                # 커밋당 한 줄로 간략히
git log --oneline --graph        # 브랜치 갈래를 그래프로
git log -3                       # 최근 3개만

💡 git log가 길게 나와 멈춘 듯 보이면 화면을 넘기는 중입니다. 스페이스로 다음 쪽, q로 빠져나옵니다. 각 줄을 누가 마지막으로 바꿨는지는 git blame <파일>로 봅니다.

7. .gitignore — 버전 관리에서 제외하기

모든 파일을 추적할 필요는 없습니다. 빌드 결과물, 설치된 패키지(node_modules), 비밀 키(.env), OS가 만드는 잡파일(.DS_Store)은 저장소에 넣지 않는 게 좋습니다. 저장소 루트에 .gitignore라는 텍스트 파일을 만들고, 제외할 패턴을 한 줄에 하나씩 적습니다.

# .gitignore 예시
node_modules/      # 폴더 전체 무시
*.log              # 모든 .log 파일
.env               # 환경변수·비밀 파일
.DS_Store          # macOS 잡파일
build/             # 빌드 산출물
!important.log     # 앞의 *.log 규칙에서 이것만 예외로 추적

패턴	의미
`이름`	해당 이름의 파일·폴더 무시
`폴더/`	그 폴더 전체 무시
`*.확장자`	해당 확장자 파일 모두 무시
`!패턴`	앞서 무시한 것 중 이것만 예외(추적)

.gitignore는 아직 추적 안 된 파일에만 적용됩니다. 이미 커밋해 버린 파일은 .gitignore에 넣어도 계속 추적됩니다. 이 경우 git rm --cached <파일>로 추적만 해제한 뒤 커밋해야 합니다.

참고 링크

git 2.5x(2.50.1) 기준 · 한국어 교육 자료 · 문서 수집일 2026-06-16
공식 문서: git-scm.com/docs