git으로 하는 일의 대부분은 '고치고 → 확인하고 → 담고 → 찍는' 네 박자의 반복입니다. 기획자 민지가 동네 카페 웹사이트 cafe-menu 저장소에서 git status로 현재 위치를 읽고, git add로 커밋할 파일을 고르고, git diff로 바뀐 줄을 확인한 뒤, git commit으로 세이브 포인트를 남기는 과정을 실제 터미널 출력과 함께 따라갑니다. .gitignore로 비밀 정보를 지키는 법, 좋은 커밋 메시지, 마지막 커밋 고치기(--amend), AI 에이전트에게 커밋을 맡길 때 확인할 것까지 다룹니다.
1편에서 민지는 git을 설치하고, 이름과 이메일을 등록하고, 동네 카페 웹사이트 폴더 cafe-menu에서 git init을 실행했습니다. 폴더 안에는 index.html, menu.md, README.md 세 파일이 있고, 이제 이 폴더는 git이 지켜보는 저장소가 되었습니다.
그런데 저장소를 만들었다고 해서 기록이 저절로 남지는 않습니다. git은 게임의 자동 저장이 아니라 수동 세이브입니다. 무엇을 언제 저장할지는 사람이 정합니다. 이번 편은 바로 그 "저장하는 손동작"을 몸에 익히는 편입니다. 명령은 다섯 개뿐입니다.
git status — 지금 어디에 있지?git diff — 정확히 뭐가 바뀌었지?git add — 이번 세이브에 무엇을 담을까?git commit — 세이브 포인트 찍기git log / git show — 지금까지 남긴 기록 보기여기에 실수했을 때 되돌리는 법(git restore --staged, git commit --amend), 올리면 안 되는 파일을 막는 .gitignore, 그리고 나중의 나와 동료가 고마워할 커밋 메시지 쓰는 법을 더합니다. 이번 편은 전부 내 컴퓨터 안에서 일어나는 일입니다. GitHub와 주고받는 건 3편에서 합니다.
8d8c3d4 같은 값)는 컴퓨터·시각·이름마다 달라지므로 여러분 화면과 다른 것이 정상입니다. 운영체제 언어 설정에 따라 git 메시지가 한국어로 나올 수도 있는데, 2장에서 두 가지를 나란히 보여 드립니다.
1편의 지도를 한 번 더 떠올려 봅시다. git에는 네 공간이 있었습니다. 작업 폴더(내가 파일을 편집하는 곳) → 스테이징 영역(다음 커밋에 담을 것을 모아 두는 곳) → 로컬 저장소(커밋이 쌓이는 곳) → 원격 저장소(GitHub 같은 공유 공간). 이번 편은 앞의 세 공간, 즉 내 컴퓨터 안에서만 움직입니다.
민지가 하루에 수십 번 반복하게 될 동작은 이렇습니다.
menu.md에 새 메뉴를 추가하는 등, 평소처럼 파일을 편집합니다. git은 아직 아무것도 하지 않습니다.git status로 어떤 파일이 바뀌었는지, git diff로 어떤 줄이 바뀌었는지 봅니다.git add 파일로 이번 커밋에 넣을 변경만 스테이징 영역에 올립니다.git commit -m "메시지"로 세이브 포인트를 남깁니다. git log로 잘 쌓였는지 확인합니다.이 네 박자에서 가장 자주 치는 명령은 의외로 git status입니다. 숙련자일수록 무언가를 하기 전과 후에 습관처럼 git status를 칩니다. 그래서 여기서부터 시작합니다.
지도 앱을 켜면 제일 먼저 파란 점, "현재 위치"를 찾습니다. git status가 바로 그 파란 점입니다. 파일을 바꾸지도, 기록을 남기지도 않고 지금 상태를 보여 주기만 하므로 몇 번을 쳐도 안전합니다. 헷갈릴 때는 언제나 이 명령부터 치면 됩니다.
git init 직후의 cafe-menu 폴더에서 실행해 봅니다.
cd cafe-menu
git status
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
README.md
index.html
menu.md
nothing added to commit but untracked files present (use "git add" to track)
한 줄씩 읽어 봅시다.
| 출력 줄 | 뜻 |
|---|---|
On branch main | 지금 main이라는 브랜치(작업 줄기) 위에 있다는 뜻. 브랜치는 4편에서 다룹니다. 지금은 "기본 줄기"라고만 알면 충분합니다. |
No commits yet | 아직 세이브 포인트가 하나도 없다는 뜻. 첫 커밋을 하면 이 줄이 사라집니다. |
Untracked files: | 추적하지 않는 파일. 폴더에는 있지만 git이 "처음 보는" 파일입니다. git은 이 파일들의 변화를 기록하지 않습니다. |
(use "git add <file>..." ...) | 괄호 안은 git이 친절하게 알려 주는 다음에 할 수 있는 명령입니다. 막혔을 때 이 힌트만 읽어도 절반은 해결됩니다. |
nothing added to commit ... | 스테이징 영역이 비어 있어서 지금 커밋하면 담을 게 없다는 요약. |
첫 커밋을 하고(5장에서 자세히 봅니다) 조금 더 작업하면 status 화면은 이렇게 세 구역으로 나뉩니다. 민지가 menu.md에 바닐라라테를 추가해 git add까지 했고, index.html도 고쳤지만 아직 담지 않았고, 개인 메모용 notes.txt를 새로 만든 상황입니다.
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: menu.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: index.html
Untracked files:
(use "git add <file>..." to include in what will be committed)
notes.txt
위에서부터 아래로 커밋에 가까운 순서라고 기억하면 쉽습니다.
| 구역 | 한국어로 풀면 | 이 파일은 지금 | 다음 동작 |
|---|---|---|---|
Changes to be committed | 커밋할 변경 사항 (스테이징됨) | 장바구니에 담김. 지금 git commit하면 들어감 | 커밋하거나, git restore --staged로 도로 빼기 |
Changes not staged for commit | 커밋하도록 정하지 않은 변경 사항 (수정됨) | git이 알고 있는 파일인데 내용이 바뀜. 아직 장바구니 밖 | git add로 담거나, 계속 작업 |
Untracked files | 추적하지 않는 파일 | git이 처음 보는 새 파일 | 기록할 거면 git add, 영영 무시할 거면 .gitignore(8장) |
modified:는 "내용이 바뀌었다", new file:은 "새로 추가될 파일이다", deleted:는 "지워졌다"는 표시입니다. 마지막 구역까지 다 비고 나면 git은 이렇게 말합니다.
On branch main
nothing to commit, working tree clean
"working tree clean" — 작업 폴더가 마지막 커밋과 똑같다는 뜻입니다. 세이브 직후의 깨끗한 상태이고, 새 작업을 시작하기에 가장 좋은 순간입니다.
Changes to be committed = 커밋할 변경 사항, Changes not staged for commit = 커밋하도록 정하지 않은 변경 사항, Untracked files = 추적하지 않는 파일, modified = 수정함. 번역이 덜 된 힌트 줄은 영어로 섞여 나오기도 합니다.
현재 브랜치 main
커밋할 변경 사항:
(use "git restore --staged <file>..." to unstage)
수정함: menu.md
커밋하도록 정하지 않은 변경 사항:
(무엇을 커밋할지 바꾸려면 "git add <파일>..."을 사용하십시오)
(use "git restore <file>..." to discard changes in working directory)
수정함: index.html
추적하지 않는 파일:
(커밋할 사항에 포함하려면 "git add <파일>..."을 사용하십시오)
notes.txt
익숙해지면 한 줄 요약이 편합니다. -s(short) 옵션을 붙입니다.
git status -s
M index.html
M menu.md
?? notes.txt
앞의 두 글자가 핵심입니다. 왼쪽 글자는 스테이징 영역, 오른쪽 글자는 작업 폴더의 상태입니다.
M (M이 왼쪽) — 수정한 내용이 스테이징됨 → 커밋하면 들어감 M (M이 오른쪽) — 수정했지만 아직 스테이징 안 됨A — 새 파일이 스테이징됨 (Added)?? — 추적하지 않는 파일MM — 한 번 스테이징한 뒤에 또 고침 (4장에서 봅니다)아래 위젯에서 여러 상황의 status 출력을 한 줄씩 눌러 보세요. 각 줄이 무슨 뜻인지, 다음에 무엇을 하면 되는지 알려 줍니다.
첫 커밋을 해 봅시다. 우선 menu.md 하나만 담아 봅니다.
git add menu.md
git status
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: menu.md
Untracked files:
(use "git add <file>..." to include in what will be committed)
README.md
index.html
menu.md가 "Untracked files"에서 "Changes to be committed"로 올라갔습니다. git add는 파일을 스테이징 영역으로 옮기는 명령입니다. 정확히는 "지금 이 순간의 파일 내용"을 복사해 올려 둡니다. 이 점이 4장에서 중요해집니다.
git rm --cached로 나온 이유는 아직 커밋이 하나도 없기 때문입니다. 첫 커밋 이후에는 같은 자리에 git restore --staged가 나옵니다. 둘 다 "장바구니에서 도로 빼기"이고, 파일 자체는 지워지지 않습니다.
마침표(.)는 "현재 폴더와 그 아래 전부"라는 뜻입니다. 저장소 맨 위 폴더에서 치면 바뀐 파일이 모두 담깁니다.
git add .
git status
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: README.md
new file: index.html
new file: menu.md
| 명령 | 장점 | 주의 |
|---|---|---|
git add menu.mdgit add menu.md index.html | 담는 것을 정확히 고를 수 있음. 커밋 단위를 깔끔하게 나누기 좋음 | 파일이 많으면 타이핑이 번거로움 |
git add . | 빠르고 편함. 바뀐 게 전부 한 가지 일일 때 적합 | 비밀 키 파일, 임시 파일, 관련 없는 수정까지 함께 쓸려 들어감. 치기 전에 반드시 git status |
git add .는 편하지만 "눈 감고 장바구니에 다 쓸어 담기"와 같습니다. 그래서 실무에서는 git status로 목록을 본 다음 git add . 하는 습관을 들이고, 올리면 안 되는 파일은 8장의 .gitignore로 아예 목록에서 사라지게 만듭니다.
처음 git을 배우는 사람이 가장 많이 묻는 질문입니다. "그냥 commit 한 번이면 될 걸, 왜 add를 따로 해야 하나요?"
온라인 쇼핑을 떠올려 보세요. 사이트를 돌아다니며 여러 물건을 봤지만, 결제 버튼을 누르기 전에 먼저 장바구니에 담습니다. 장바구니에서 빼기도 하고, 이번에는 이것만 사고 나머지는 다음에 사기도 합니다. 결제(커밋)는 장바구니에 담긴 것만 한 번에 처리합니다.
git의 스테이징 영역이 바로 그 장바구니입니다. 민지가 오전 내내 작업한 결과가 이렇다고 합시다.
menu.md: 바닐라라테 추가index.html: 영업시간 문구 추가README.md: 오타 수정세 가지는 서로 다른 일입니다. 스테이징이 없다면 "오전 작업"이라는 커밋 하나에 전부 뭉쳐 들어갑니다. 스테이징이 있으니 이렇게 나눌 수 있습니다.
이렇게 나눠 두면 나중에 "영업시간 문구만 되돌려 주세요"라는 요청이 왔을 때 그 커밋 하나만 되돌리면 됩니다(되돌리기는 5편). 뭉쳐 있었다면 메뉴와 오타 수정까지 같이 딸려 나갑니다. 스테이징은 "커밋 단위를 고르는 곳"입니다.
git add -p 파일을 치면 바뀐 덩어리마다 "이것도 담을까요?"라고 물어보고 y/n으로 고를 수 있습니다. 당장 필요하지는 않지만, 커밋을 깔끔하게 나누고 싶어질 때 떠올리세요.
아래 위젯에서 직접 장바구니를 채워 보세요. 바뀐 파일 중 어떤 것을 담느냐에 따라 만들어지는 커밋이 어떻게 달라지는지, 무엇을 담으면 안 되는지 볼 수 있습니다.
git status는 어떤 파일이 바뀌었는지 알려 줍니다. 그 파일의 어떤 줄이 바뀌었는지는 git diff가 보여 줍니다. 첫 커밋을 마친 민지가 menu.md에 바닐라라테를, index.html에 영업시간을 추가했습니다.
git diff
diff --git a/index.html b/index.html
index 1fb203e..3ce61f3 100644
--- a/index.html
+++ b/index.html
@@ -4,5 +4,6 @@
<body>
<h1>동네 카페</h1>
<p>오늘도 따뜻한 커피 한 잔.</p>
+ <p>영업시간: 매일 8:00 ~ 21:00</p>
</body>
</html>
diff --git a/menu.md b/menu.md
index 77b5a93..79b3b5d 100644
--- a/menu.md
+++ b/menu.md
@@ -2,3 +2,4 @@
- 아메리카노 4,000원
- 카페라테 4,500원
+- 바닐라라테 5,000원
처음 보면 암호 같지만, 읽어야 할 것은 세 가지뿐입니다.
한 줄을 고치면 diff에는 "원래 줄 삭제 + 새 줄 추가"로 나옵니다. 나중에 민지가 아메리카노 가격을 올렸을 때의 diff입니다.
@@ -1,5 +1,5 @@
# 메뉴
-- 아메리카노 4,000원
+- 아메리카노 4,300원
- 카페라테 4,500원
- 바닐라라테 5,000원
q를 누르면 빠져나옵니다. 터미널이 멈춘 것처럼 보이면 대부분 이 상태입니다.
여기서 많은 사람이 한 번씩 헷갈립니다. 민지가 menu.md만 담고 다시 git diff를 쳤습니다.
git add menu.md
git diff
diff --git a/index.html b/index.html
index 1fb203e..3ce61f3 100644
--- a/index.html
+++ b/index.html
@@ -4,5 +4,6 @@
<body>
<h1>동네 카페</h1>
<p>오늘도 따뜻한 커피 한 잔.</p>
+ <p>영업시간: 매일 8:00 ~ 21:00</p>
</body>
</html>
menu.md의 변경이 사라졌습니다! 없어진 게 아닙니다. git diff는 "아직 담지 않은 변경"만 보여 주기 때문입니다. 장바구니에 담긴 쪽을 보려면 --staged를 붙입니다.
git diff --staged
diff --git a/menu.md b/menu.md
index 77b5a93..79b3b5d 100644
--- a/menu.md
+++ b/menu.md
@@ -2,3 +2,4 @@
- 아메리카노 4,000원
- 카페라테 4,500원
+- 바닐라라테 5,000원
| 명령 | 무엇과 무엇을 비교하나 | 언제 치나 |
|---|---|---|
git diff | 스테이징 영역 ↔ 작업 폴더 (= 아직 담지 않은 변경) | "뭘 고쳤더라?" 담기 전에 |
git diff --staged | 마지막 커밋 ↔ 스테이징 영역 (= 담아 둔 변경, 곧 커밋될 내용) | 커밋 직전 최종 확인 |
--staged와 --cached는 같은 옵션입니다. 다른 글에서 git diff --cached를 보더라도 같은 뜻입니다.
커밋 직전에 git diff --staged를 한 번 보는 습관은 이번 편에서 가장 값진 습관 중 하나입니다. 실수로 들어간 디버깅용 문구, 지우려던 줄, 엉뚱한 파일을 여기서 잡아낼 수 있습니다.
git add는 "그 순간의 내용"을 담는다고 했습니다. 그러면 담은 뒤에 같은 파일을 또 고치면 어떻게 될까요? 민지가 아메리카노 가격을 올려 git add한 다음, 카페라테 가격도 올렸습니다.
git add menu.md
# (에디터에서 카페라테 가격도 수정)
git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: menu.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: menu.md
같은 menu.md가 두 구역에 동시에 나옵니다. git status -s로 보면 MM menu.md입니다. 장바구니에는 아메리카노만 바뀐 버전이, 작업 폴더에는 둘 다 바뀐 버전이 있습니다. 두 diff로 확인하면 분명해집니다.
git diff --staged
diff --git a/menu.md b/menu.md
index 79b3b5d..6ae77fb 100644
--- a/menu.md
+++ b/menu.md
@@ -1,5 +1,5 @@
# 메뉴
-- 아메리카노 4,000원
+- 아메리카노 4,300원
- 카페라테 4,500원
- 바닐라라테 5,000원
git diff
diff --git a/menu.md b/menu.md
index 6ae77fb..c9f5bc7 100644
--- a/menu.md
+++ b/menu.md
@@ -1,5 +1,5 @@
# 메뉴
- 아메리카노 4,300원
-- 카페라테 4,500원
+- 카페라테 4,800원
- 바닐라라테 5,000원
장바구니 쪽(--staged)에서는 카페라테가 아직 4,500원이고, 작업 폴더 쪽(git diff)에서만 4,800원으로 바뀌어 있습니다. 이 상태에서 바로 커밋하면 아메리카노 인상만 기록되고 카페라테 인상은 빠집니다. 둘 다 넣고 싶다면 git add menu.md를 한 번 더 하면 됩니다. "고친 뒤에는 다시 add"라고 기억하세요.
세 파일을 모두 담은 상태에서 첫 커밋을 합니다. -m 뒤에 따옴표로 커밋 메시지(이 세이브 포인트에 붙이는 설명)를 씁니다.
git commit -m "카페 웹사이트 첫 뼈대 추가"
[main (root-commit) 8d8c3d4] 카페 웹사이트 첫 뼈대 추가
3 files changed, 15 insertions(+)
create mode 100644 README.md
create mode 100644 index.html
create mode 100644 menu.md
main — main 브랜치에 커밋했다(root-commit) — 저장소의 첫 번째 커밋(뿌리)이라는 표시. 이후 커밋에는 붙지 않습니다8d8c3d4 — 이 커밋의 해시(고유 번호)의 앞 7자리3 files changed, 15 insertions(+) — 파일 3개, 15줄이 추가됨create mode 100644 — 새로 생긴 파일(100644는 "일반 파일"이라는 권한 표시로, 신경 쓰지 않아도 됩니다)이제 status를 보면 깨끗합니다.
On branch main
nothing to commit, working tree clean
이어서 민지는 4장에서 담아 둔 바닐라라테를 커밋하고, 영업시간도 따로 커밋했습니다.
git commit -m "메뉴에 바닐라라테 추가"
git add index.html
git commit -m "첫 화면에 영업시간 표시"
[main b5fc16c] 메뉴에 바닐라라테 추가
1 file changed, 1 insertion(+)
[main b1c95d6] 첫 화면에 영업시간 표시
1 file changed, 1 insertion(+)
-m 없이 git commit만 치면 메시지를 쓰라고 텍스트 에디터가 열립니다. 에디터를 따로 설정하지 않았다면 vi 계열이 뜨는 경우가 많은데, 처음 보면 당황스럽습니다. 당황했다면 i를 눌러 메시지를 쓰고, Esc를 누른 뒤 :wq와 엔터로 저장·종료하세요. 메시지를 비워 두고 닫으면 커밋은 취소됩니다. 입문 단계에서는 -m을 쓰는 편이 편합니다.
아무것도 담지 않고 커밋하려 하면 git이 거절하고 status 화면을 대신 보여 줍니다. 파일을 고쳤는데 add를 잊은 경우입니다.
git commit -m "메뉴 수정"
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: index.html
modified: menu.md
Untracked files:
(use "git add <file>..." to include in what will be committed)
notes.txt
no changes added to commit (use "git add" and/or "git commit -a")
마지막 줄 no changes added to commit — "장바구니가 비어 있다"는 뜻입니다. 커밋은 만들어지지 않았으니 git add부터 하면 됩니다. 바뀐 파일이 하나도 없을 때는 nothing to commit, working tree clean이 나옵니다.
커밋은 "바뀐 부분만" 저장한 것처럼 보이지만, git의 관점에서는 그 순간 프로젝트 전체의 사진(스냅샷)입니다. 커밋 안을 직접 열어 볼 수도 있습니다.
git cat-file -p HEAD
tree 7eb26c3661fedaed8d2755174458e12e7e020237
parent b5fc16c1df03864ba0a7cd259a8d86d0c67994ba
author 민지 <minji@example.com> 1790732100 +0900
committer 민지 <minji@example.com> 1790732100 +0900
첫 화면에 영업시간 표시
HEAD는 "지금 내가 서 있는 커밋", 보통은 가장 최근 커밋을 가리키는 이름입니다. 이 명령을 외울 필요는 없습니다. 커밋 안에 무엇이 있는지 한 번 눈으로 보는 것으로 충분합니다.
| 구성 요소 | 뜻 | 비유 |
|---|---|---|
| 스냅샷 (tree) | 그 순간 모든 파일의 상태. 바뀌지 않은 파일은 이전 것을 그대로 가리켜서 용량을 아낍니다 | 세이브 파일 속 게임 전체 상태 |
| 해시 | 커밋 내용 전체로 계산한 40자리 16진수 고유 번호. 보통 앞 7자리로 부릅니다. 내용이 한 글자만 달라도 완전히 다른 값이 됩니다 | 세이브 슬롯 번호 + 봉인 스티커 |
| 부모 (parent) | 바로 앞 커밋의 해시. 이 연결 덕분에 커밋들이 한 줄의 역사가 됩니다. 첫 커밋에는 부모가 없습니다 | "이전 세이브에서 이어짐" |
| 작성자·시각 (author) | 1편에서 git config로 등록한 이름·이메일, 그리고 커밋 시각 | 세이브한 사람과 날짜 |
| 메시지 | 무엇을 왜 했는지 사람이 쓴 설명 | 세이브 슬롯에 붙인 메모 |
해시가 "내용 전체로 계산한 값"이라는 점이 중요합니다. 부모 해시도 계산에 들어가기 때문에, 과거 커밋 하나를 몰래 고치면 그 뒤의 해시가 줄줄이 바뀝니다. 그래서 git의 기록은 조용히 위조하기 어렵습니다. 7장의 --amend가 "커밋을 고치는 게 아니라 새로 만드는 것"인 이유도 여기에 있습니다.
git log
commit 8d8c3d42e9c8646bb60c818a55fc8737743d2f07
Author: 민지 <minji@example.com>
Date: Wed Sep 30 10:12:00 2026 +0900
카페 웹사이트 첫 뼈대 추가
첫 커밋 직후라 하나뿐입니다. 커밋이 쌓이면 최신 것이 맨 위에 옵니다. 해시 전체(40자리), 작성자, 날짜, 메시지가 보입니다.
커밋이 몇 개만 되어도 git log는 길어집니다. 평소에는 --oneline을 씁니다.
git log --oneline
b1c95d6 첫 화면에 영업시간 표시
b5fc16c 메뉴에 바닐라라테 추가
8d8c3d4 카페 웹사이트 첫 뼈대 추가
아래에서 위로 읽으면 이 카페 웹사이트의 역사입니다. 뼈대를 만들고 → 메뉴를 추가하고 → 영업시간을 넣었습니다. 메시지만 읽어도 무슨 일이 있었는지 알 수 있습니다. 9장에서 커밋 메시지를 공들여 쓰라고 하는 이유가 바로 이 화면입니다.
최근 몇 개만 보고 싶으면 git log --oneline -3처럼 개수를 붙입니다.
특정 커밋에서 무엇이 바뀌었는지 보려면 git show를 씁니다. 해시를 주지 않으면 가장 최근 커밋을 보여 줍니다.
git show
commit b1c95d6dbcd3e056c42e2339d35312ae17d07cf6
Author: 민지 <minji@example.com>
Date: Wed Sep 30 10:35:00 2026 +0900
첫 화면에 영업시간 표시
diff --git a/index.html b/index.html
index 1fb203e..3ce61f3 100644
--- a/index.html
+++ b/index.html
@@ -4,5 +4,6 @@
<body>
<h1>동네 카페</h1>
<p>오늘도 따뜻한 커피 한 잔.</p>
+ <p>영업시간: 매일 8:00 ~ 21:00</p>
</body>
</html>
커밋 정보 + 그 커밋의 diff입니다. 특정 커밋을 보려면 해시 앞자리를 붙이고, 어떤 파일이 몇 줄 바뀌었는지만 보려면 --stat을 붙입니다. HEAD~1은 "HEAD에서 하나 전 커밋"이라는 뜻입니다.
git show --stat HEAD~1
commit b5fc16c1df03864ba0a7cd259a8d86d0c67994ba
Author: 민지 <minji@example.com>
Date: Wed Sep 30 10:31:00 2026 +0900
메뉴에 바닐라라테 추가
menu.md | 1 +
1 file changed, 1 insertion(+)
| 명령 | 보여 주는 것 |
|---|---|
git log | 커밋 목록 (해시 전체·작성자·날짜·메시지) |
git log --oneline | 커밋 목록을 한 줄씩. 가장 자주 씀 |
git show | 최근 커밋 하나의 정보 + diff |
git show b5fc16c | 해당 해시 커밋의 정보 + diff |
git show --stat HEAD~1 | 하나 전 커밋에서 바뀐 파일 목록과 줄 수 |
실수는 반드시 합니다. 다행히 이번 편에서 자주 하는 실수 두 가지는 되돌리기 쉽습니다. (이미 한참 지난 커밋을 되돌리는 법, 파일 수정 자체를 버리는 법은 5편에서 자세히 다룹니다.)
index.html을 담았는데, 생각해 보니 이번 커밋에는 넣고 싶지 않습니다.
git add index.html
git status -s
M index.html
git restore --staged index.html
git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")
index.html이 장바구니 밖으로 나왔습니다. 고친 내용은 그대로 남아 있습니다. git restore --staged는 "담기 취소"일 뿐 파일을 건드리지 않습니다.
--staged를 빼먹지 마세요. 힌트 줄에 보이는 git restore <file>(--staged 없음)는 전혀 다른 명령입니다. 작업 폴더의 수정 내용을 버리고 마지막 상태로 되돌립니다. 커밋하지 않은 수정은 git에 기록이 없으니 되살릴 방법도 없습니다. 예전 글에서 보이는 git checkout -- 파일이나 git reset HEAD 파일은 같은 일을 하던 예전 방식입니다.
민지가 가격 인상을 커밋했는데, 메시지에 오타가 났고 카페라테 변경은 담는 것을 잊었습니다(4장의 MM 상태에서 그대로 커밋해 버린 것입니다).
git commit -m "아메리카노 가걱 인상"
[main a7c0665] 아메리카노 가걱 인상
1 file changed, 1 insertion(+), 1 deletion(-)
메시지만 고치기 — --amend에 새 메시지를 줍니다.
git commit --amend -m "커피 가격 인상: 아메리카노 4,300원, 카페라테 4,800원"
[main c3de27a] 커피 가격 인상: 아메리카노 4,300원, 카페라테 4,800원
Date: Wed Sep 30 11:05:00 2026 +0900
1 file changed, 1 insertion(+), 1 deletion(-)
빠뜨린 변경 추가하기 — 담은 다음 --amend --no-edit(메시지는 그대로 둠)을 칩니다.
git add menu.md
git commit --amend --no-edit
[main 95e7ec9] 커피 가격 인상: 아메리카노 4,300원, 카페라테 4,800원
Date: Wed Sep 30 11:05:00 2026 +0900
1 file changed, 2 insertions(+), 2 deletions(-)
git log --oneline
95e7ec9 커피 가격 인상: 아메리카노 4,300원, 카페라테 4,800원
af09d42 .gitignore 추가: node_modules, .env, .DS_Store 제외
b1c95d6 첫 화면에 영업시간 표시
b5fc16c 메뉴에 바닐라라테 추가
8d8c3d4 카페 웹사이트 첫 뼈대 추가
(af09d42는 8장에서 만들 .gitignore 커밋입니다. 순서상 이 시점에는 이미 있었습니다.)
오타 난 커밋이 목록에서 사라지고 고친 커밋 하나만 남았습니다. 해시를 잘 보세요. a7c0665 → c3de27a → 95e7ec9로 매번 바뀌었습니다. --amend는 기존 커밋을 수정하는 것이 아니라, 고친 내용으로 새 커밋을 만들어 바꿔 끼우는 것이기 때문입니다. 출력의 Date: 줄은 원래 작성 시각(11:05)이 유지된다는 표시입니다.
cafe-menu에 지도 기능을 붙이면서 폴더에 파일이 몇 개 생겼습니다. 지도 서비스의 API 키를 넣은 .env, 패키지 설치로 생긴 node_modules/ 폴더, 그리고 macOS가 폴더를 열 때 자동으로 만드는 .DS_Store입니다.
On branch main
Untracked files:
(use "git add <file>..." to include in what will be committed)
.DS_Store
.env
node_modules/
nothing added to commit but untracked files present (use "git add" to track)
이 상태에서 무심코 git add .를 치면 셋 다 장바구니에 들어갑니다.
| 파일 | 무엇인가 | 왜 커밋하면 안 되나 |
|---|---|---|
.env | API 키·비밀번호 같은 비밀 설정 | 한 번 커밋되면 기록에 영원히 남습니다. 저장소가 공개되거나 공유되는 순간 키가 새어 나갑니다 |
node_modules/ | npm 등으로 설치한 외부 패키지 (수천~수만 개 파일) | 용량이 크고, npm install로 언제든 다시 받을 수 있음. 목록(package.json)만 커밋하면 됨 |
.DS_Store | macOS Finder가 만드는 폴더 표시 정보 | 프로젝트와 무관하고, 사람마다 달라서 쓸데없는 변경만 만듦 |
저장소 맨 위 폴더에 .gitignore라는 이름의 텍스트 파일을 만들고, 무시할 파일 이름이나 패턴을 한 줄에 하나씩 적습니다. #으로 시작하는 줄은 메모입니다.
cat > .gitignore <<'EOF'
# 의존성 폴더 (npm install로 언제든 다시 받을 수 있음)
node_modules/
# 비밀 정보 — 절대 커밋하지 않는다
.env
# macOS가 자동으로 만드는 파일
.DS_Store
EOF
(에디터로 .gitignore 파일을 만들어 같은 내용을 붙여 넣어도 됩니다.) 이제 status를 다시 봅니다.
git status
On branch main
Untracked files:
(use "git add <file>..." to include in what will be committed)
.gitignore
nothing added to commit but untracked files present (use "git add" to track)
세 파일이 목록에서 사라지고 .gitignore 자신만 남았습니다. 파일이 지워진 게 아니라 git이 못 본 척하는 것입니다. .gitignore는 팀 전체가 같은 규칙을 쓰도록 커밋해 둡니다.
git add .gitignore
git commit -m ".gitignore 추가: node_modules, .env, .DS_Store 제외"
[main af09d42] .gitignore 추가: node_modules, .env, .DS_Store 제외
1 file changed, 8 insertions(+)
create mode 100644 .gitignore
어떤 파일이 왜 무시되는지 궁금하면 git check-ignore -v로 확인할 수 있습니다. 몇 번째 줄 규칙 때문인지 알려 줍니다.
git check-ignore -v .env .DS_Store node_modules/lodash/index.js
.gitignore:5:.env .env
.gitignore:8:.DS_Store .DS_Store
.gitignore:2:node_modules/ node_modules/lodash/index.js
.gitignore는 아직 추적하지 않는 파일에만 효과가 있습니다. 이미 커밋된 파일은 목록에 적어도 계속 추적됩니다. 민지가 .gitignore를 만들기 전에 .env를 커밋해 버린 경우를 재현해 봤습니다. .gitignore에 .env를 적은 뒤 키 값을 바꾸자 이렇게 나옵니다.
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: .env
Untracked files:
(use "git add <file>..." to include in what will be committed)
.gitignore
.env가 여전히 "modified"로 추적됩니다. 이럴 때는 git rm --cached로 추적만 중단합니다. --cached가 붙으면 내 컴퓨터의 파일은 그대로 두고 저장소에서만 뺍니다.
git rm --cached .env
git add .gitignore
git status
rm '.env'
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: .env
new file: .gitignore
git commit -m ".env 추적 중단, .gitignore 추가"
[main 9a095c4] .env 추적 중단, .gitignore 추가
2 files changed, 8 insertions(+), 1 deletion(-)
delete mode 100644 .env
create mode 100644 .gitignore
git rm --cached는 "앞으로" 추적을 멈출 뿐, 과거 커밋 안의 .env는 그대로 남아 있습니다. git show로 옛 커밋을 열면 키가 보입니다. 특히 이미 push했다면 누군가 복사해 갔다고 가정해야 합니다. 기록에서 지우는 방법도 있지만 복잡하고 완벽하지 않으므로, 가장 확실한 대응은 해당 서비스에서 키를 폐기하고 새로 발급하는 것입니다. 그래서 새 프로젝트를 만들면 첫 커밋 전에 .gitignore부터 만드는 것이 좋습니다.
git log --oneline을 다시 떠올려 보세요. 몇 달 뒤 민지나 도윤이 "영업시간은 언제 바뀌었지?"를 찾을 때 읽는 것은 코드가 아니라 커밋 메시지 목록입니다. 커밋 메시지는 미래의 나와 동료에게 보내는 편지입니다.
3장의 장바구니를 쓰는 이유가 이것입니다. "메뉴 추가"와 "영업시간 수정"과 "오타 수정"은 세 개의 커밋이어야 합니다. 판단 기준은 간단합니다. 커밋 메시지를 한 문장으로 쓸 수 있는가? 메시지에 "그리고", "및", "등"이 자꾸 들어간다면 커밋을 나눠야 한다는 신호입니다.
반대로 너무 잘게 쪼갤 필요도 없습니다. 메뉴 세 개를 한꺼번에 추가했다면 "가을 신메뉴 3종 추가" 커밋 하나가 자연스럽습니다. 되돌릴 때 같이 되돌려야 하는 것은 한 커밋에, 따로 되돌릴 수 있어야 하는 것은 다른 커밋에 넣는다고 생각하면 됩니다.
git log --oneline 한 줄에 편하게 읽히는 길이, 대략 30자 안팎을 목표로 하면 적당합니다.-m을 두 번 쓰면 첫 번째가 제목, 두 번째가 본문이 됩니다.git commit -m "영업시간을 21시에서 22시로 연장" -m "10월부터 저녁 손님이 늘어 점주 요청으로 변경. 주말 포함."
| 나쁜 예 | 좋은 예 | 무엇이 다른가 |
|---|---|---|
| 수정 | 메뉴판 카페라테 가격 오타 수정 (4,50원 → 4,500원) | 무엇을 고쳤는지 알 수 있음 |
| asdf | 첫 화면에 영업시간 표시 | 의미 없는 문자열은 기록이 아님 |
| 오늘 작업 | 가을 신메뉴 3종 추가 | 날짜는 git이 이미 기록함. 내용을 써야 함 |
| 메뉴 추가하고 영업시간 바꾸고 README 오타도 고침 | 커밋 3개로 나누기 | "그리고"가 들어가면 커밋을 쪼갤 신호 |
| 최종_진짜최종 | 예약 버튼 문구를 '예약하기'로 통일 | git이 있으니 파일명에 '최종'을 붙일 일이 없음 |
| 버그 고침 | 모바일에서 메뉴 사진이 잘리는 문제 해결 | 어떤 버그인지, 어디서 생겼는지 드러남 |
feat: 예약 폼 추가, fix: 가격 오타 수정, docs: README 설치 방법 보강처럼 앞에 종류를 붙이는 방식(흔히 Conventional Commits라고 부릅니다)입니다. 규칙이 있는 팀이면 그 규칙을 따르고, 없으면 굳이 처음부터 도입할 필요는 없습니다. 중요한 건 형식보다 읽고 무슨 일인지 아는가입니다.
아래 위젯에서 두 메시지 중 더 나은 쪽을 골라 보세요. 고르면 이유를 알려 줍니다.
Claude Code 같은 AI 코딩 도구는 터미널에서 git status, git diff, git add, git commit을 직접 실행할 수 있습니다. 파일을 고치고 커밋까지 한 번에 맡길 수도 있습니다. 그렇다고 이번 편에서 배운 것이 쓸모없어지지 않습니다. 오히려 에이전트가 만든 변경을 사람이 확인하는 도구가 바로 status·diff·log입니다.
사람이 확인할 지점은 딱 두 군데입니다. 커밋 직전의 git diff --staged(무엇이 담겼나), 커밋 직후의 git log --oneline(메시지가 한 가지 일을 말하는가). Claude Code는 명령을 실행하기 전에 권한을 묻도록 설정할 수 있는데, 그 창에 git commit이 보이면 바로 승인하기 전에 위 두 가지를 떠올리면 됩니다. 에이전트의 권한 설정과 위험한 명령을 다루는 법은 7편에서 자세히 다룹니다.
Q1. git add를 하고 나서 파일을 또 고쳤어요. 다시 add해야 하나요?
네. git add는 그 순간의 내용을 담아 둡니다. 이후의 수정은 따로 담아야 커밋에 들어갑니다. git status에서 같은 파일이 위아래 두 구역에 모두 보이거나 git status -s에서 MM이 보이면 이 상태입니다(4장).
Q2. 커밋은 얼마나 자주 해야 하나요?
"한 가지 일이 끝날 때마다"가 기준입니다. 메뉴 하나 추가, 오타 하나 수정도 한 가지 일입니다. 하루에 한 번 몰아서 커밋하면 여러 일이 뒤섞여 되돌리기 어려워집니다. 입문 단계에서는 약간 자주 하는 쪽이 늘 낫습니다. 커밋은 push하기 전까지 내 컴퓨터에만 있으니 부담 가질 필요가 없습니다.
Q3. git commit -a는 뭔가요?
이미 추적 중인 파일의 수정을 자동으로 담아 바로 커밋하는 지름길입니다(git commit -am "메시지"). 편하지만 새 파일(untracked)은 담지 않고, 무엇이 들어가는지 고르는 단계를 건너뜁니다. 스테이징에 익숙해질 때까지는 git add와 git commit을 따로 쓰길 권합니다.
Q4. 커밋 메시지를 영어로 써야 하나요?
아닙니다. 이 글의 예시처럼 한국어 커밋 메시지는 잘 동작합니다. 팀원들이 가장 빨리 이해하는 언어로 쓰고, 팀 안에서 통일하면 됩니다. 오픈소스처럼 해외 기여자가 있는 저장소라면 그 프로젝트의 관례(대개 영어)를 따릅니다.
Q5. 빈 폴더는 왜 커밋이 안 되나요?
git은 파일을 추적하지 폴더를 추적하지 않습니다. 빈 폴더를 남기고 싶다면 그 안에 설명용 파일(예: README.md)을 하나 넣어 커밋합니다. 관례적으로 .gitkeep이라는 빈 파일을 넣기도 하는데, 이 이름에 git이 특별한 의미를 두는 것은 아니고 그냥 사람들 사이의 약속입니다.
Q6. --amend를 했는데 이전 커밋이 필요해졌어요.
amend 전 커밋은 목록에서 안 보일 뿐 한동안 저장소에 남아 있어서 되찾을 수 있습니다. git reflog라는 "내가 움직인 기록"을 이용하는데, 5편에서 되돌리기와 함께 다룹니다.
| 하고 싶은 일 | 명령 | 기억할 점 |
|---|---|---|
| 지금 상태 보기 | git status / git status -s | 헷갈리면 언제나 이것부터. 아무것도 바꾸지 않음 |
| 아직 안 담은 변경 보기 | git diff | + 추가된 줄, - 없어진 줄. q로 나가기 |
| 담아 둔 변경 보기 | git diff --staged | 커밋 직전 최종 확인 습관 |
| 파일 골라 담기 | git add 파일 | 커밋 단위를 고르는 곳 |
| 전부 담기 | git add . | 치기 전에 status 확인 |
| 담기 취소 | git restore --staged 파일 | 수정 내용은 그대로. --staged 빼먹지 않기 |
| 커밋 | git commit -m "메시지" | 한 커밋 한 가지 일 |
| 기록 한눈에 | git log --oneline | 최신이 맨 위 |
| 커밋 하나 열기 | git show / git show 해시 | --stat으로 파일 목록만 |
| 마지막 커밋 고치기 | git commit --amend -m "새 메시지"git commit --amend --no-edit | push 전에만 |
| 파일 무시하기 | .gitignore에 한 줄 추가 | 첫 커밋 전에 만들기 |
| 이미 추적 중인 파일 빼기 | git rm --cached 파일 | 비밀 키였다면 키부터 재발급 |
git이 내부에서 이 기록들을 어떻게 저장하는지, 역사까지 궁금하다면 Git 완전 정복도 함께 읽어 보세요.
이제 민지의 컴퓨터에는 카페 웹사이트의 세이브 포인트가 차곡차곡 쌓였습니다. 하지만 이 기록은 아직 민지의 노트북 안에만 있습니다. 노트북이 고장 나면 사라지고, 도윤은 볼 수도 없습니다.
3편에서는 GitHub에 저장소를 만들고, git push로 커밋을 올리고, git pull로 도윤의 커밋을 받아 오는 법을 배웁니다. 매일 아침 pull로 시작해서 push로 끝나는 하루 루틴과, push가 거절(rejected)될 때 당황하지 않는 법도 함께 다룹니다.
