Git 기본

이 카드를 다루는 수업 자료를 잘 정리하는 법 Codex부터 GitHub 저장까지

주황색 퍼핏이 갈림길 위에 깃발 모양 체크포인트를 꽂아 둔 그림 — 브랜치에서 시도하고 diff로 확인한 뒤 commit하면 되돌릴 지점이 남습니다

파일이 직접 바뀌는 만큼, 무엇이 어떻게 달라졌는지 확인할 방법이 없으면 결과가 마음에 안 들어도 되돌리기 어렵습니다. Git이 그 방법입니다.

branch(작업 갈래)를 나눠 두면 실험적인 요청과 완성된 작업을 분리할 수 있습니다.

새 작업을 시작할 때 branch를 하나 만들고, 그 안에서 Claude에게 작업을 맡깁니다.
결과를 그대로 받아들이기 전에 diff(변경 내역 화면)를 봅니다.
어떤 줄이 지워지고 어떤 줄이 추가됐는지 보면, 의도와 다르게 바뀐 부분을 commit(기록) 전에 잡을 수 있습니다.

기획서 여러 장을 한 번에 고쳐 달라고 맡긴 뒤 diff를 보지 않고 그대로 commit하는 것은 피해야 할 습관입니다. 의도와 다르게 지워진 문단이 나중에야 발견됩니다.

뉴스레터 문구를 수정할 때도 마찬가지로, commit 전에 “무엇이 바뀌었는지 보여줘”라고 요청해 diff를 확인하면 커밋 전에 실수를 잡을 수 있습니다.
commit은 확인이 끝난 상태를 기록하는 지점입니다. 문제가 있으면 commit 이전으로 되돌릴 수 있으므로, 큰 작업을 맡기기 전에 commit해 두면 안전망이 생깁니다.

순서의 각 단계 아래 붙여넣기 예제가 있습니다. 위에서부터 하나씩 실행해 보세요.

실행 순서

따라하기 덱으로 열기 →

git status로 현재 상태를 확인합니다.
```
지금 git 상태를 보여줘. 변경된 파일이 있는지, 지금 어떤 branch에 있는지 확인해 줘.
```
확인현재 branch와 변경된 파일 목록이 나옵니다.

이 단계의 실제 화면

화면에서 확인할 것 Claude가 Ran 1 shell command 줄에서 명령을 한 번 실행하고 그 결과를 문장으로 풀어 줍니다. 이 화면은 바꿀 것이 없는 상태라 커밋 하나만 있는 저장소로 나옵니다. Claude Code 2.1.234 · 2026-08-19
작업용 branch를 새로 만듭니다.
```
지금 작업을 위한 새 branch를 하나 만들어 줘.
```
확인새 branch가 만들어지고 그 위로 이동합니다.

이 단계의 실제 화면

화면에서 확인할 것 이름을 주지 않으면 날짜로 된 이름이 붙고, 바꾸는 명령까지 함께 알려 줍니다. Claude Code 2.1.234 · 2026-08-19
Claude에게 원하는 변경을 요청합니다.
변경된 내용을 diff로 확인합니다.
```
방금까지 바뀐 파일들의 diff를 보여주고, 그중에 위험해 보이는 변경이 있으면 짚어 줘.
```
확인변경된 파일 목록과 줄 단위 diff가 나오고, 되돌리기 어렵거나 의도와 어긋나 보이는 변경에 지적이 몇 줄 붙습니다.

이 단계의 실제 화면

화면에서 확인할 것 추가된 줄이 초록색으로 표시되고, 그 아래에 위험한 변경이 있는지 판단이 붙습니다. Claude Code 2.1.234 · 2026-08-19
확인이 끝난 상태를 commit으로 기록합니다.
```
확인이 끝났으니 지금 상태를 commit으로 기록해 줘.
```
확인지금까지 확인한 변경이 commit으로 기록됩니다.

이 단계의 실제 화면

화면에서 확인할 것 커밋이 만들어지면 해시와 브랜치, 바뀐 범위가 함께 표시됩니다. Claude Code 2.1.234 · 2026-08-19

직접 해보기

대괄호 안은 실제 값으로 바꿔서 붙여넣습니다.

내 상황에 맞춰

[작업 중인 파일 또는 폴더]에서 최근 바뀐 내용을 diff로 보여주고, 의도한 변경이 맞는지 같이 확인해 줘.

한 단계 더

이 diff를 논리적으로 묶이는 단위로 커밋 2~3개로 쪼개고, 각 커밋 메시지 초안을 제안해 줘.

diff에서 위험하다고 짚어 준 부분이 실제로 의도한 변경인지 확인해 보세요.

헷갈리기 쉬운 것

diff를 보지 않고 커밋하면 의도하지 않은 변경이 기록에 그대로 섞여 들어갑니다. 이때는 커밋 전에 반드시 diff로 바뀐 줄을 확인합니다. main(기본) branch에서 바로 실험하면 문제가 생겼을 때 되돌릴 기준점이 없으므로, 실험은 항상 별도 branch에서 시작합니다.

왜 이렇게 작동하나요

문서를 크게 고치기 전에 사본을 하나 만들어 두는 습관을 떠올려 보세요. 원본은 그대로 두고 사본에서 고치면 결과가 마음에 들지 않을 때 사본만 버리면 됩니다. branch가 그 사본에 해당하고 commit은 사본을 저장해 둔 시점에 해당합니다. 이해를 돕기 위한 비유입니다.

git은 파일의 지금 모습만 들고 있는 것이 아니라 언제 무엇이 바뀌었는지를 기록으로 쌓습니다. commit을 남긴 시점은 되돌릴 기준이 되고, branch는 변경 기록을 나눠 main을 유지한 채 시도해 보게 합니다.

더 알고 싶다면

branch 이름을 정해 주지 않으면 어떻게 되나요?

무슨 작업을 할지 아직 말하지 않았으면 이름을 지을 근거가 없어서, 오늘 날짜를 붙인 이름이 만들어집니다. 2026년 8월 19일에 실행하면 work-2026-08-19 같은 이름이 나오고, 같은 요청을 다시 해도 work/2026-08-19처럼 구분 기호가 달라지거나 이름을 먼저 물어보는 경우가 있습니다.
화면에 보이는 이름과 다른 이름이 나와도 잘못된 것이 아닙니다. 무슨 작업인지 이미 정해졌으면 요청에 이름을 함께 적고, 만든 뒤에 바꾸고 싶으면 git branch -m 새이름으로 고칩니다.

diff에서 무엇을 먼저 봐야 하나요?

추가된 줄보다 지워진 줄을 먼저 봅니다. 추가는 마음에 안 들면 다시 지우면 되지만, 의도하지 않은 삭제는 원래 내용을 기억하지 못하면 되살리기 어렵습니다.
그다음으로 실행되는 코드와 비밀번호·키가 섞였는지 봅니다. 메모나 원고처럼 읽기만 하는 파일이면 위험이 낮고, 실행되는 파일이거나 .env 같은 설정 파일이면 커밋 전에 한 줄씩 확인합니다.

용어 풀이

전체 용어집 →

Git: 파일이 바뀐 기록을 남기고 이전 상태로 되돌릴 수 있게 해 주는 도구입니다. 코드뿐 아니라 텍스트 파일이면 어디에나 쓸 수 있습니다.
branch(브랜치): 변경 기록을 나눠 진행할 때 붙이는 이름입니다. main을 유지하면서 새 브랜치에서 실험할 수 있습니다.
diff(디프): 파일에서 어떤 줄이 지워지고 어떤 줄이 추가됐는지 한눈에 보여 주는 화면입니다.
commit(커밋): 지금까지 확인한 변경 내용을 하나의 기록으로 저장하는 행동입니다. 문제가 생기면 commit 이전 상태로 되돌아갈 수 있습니다.

2026-07-13 기준 · 출처 · Claude Code — Common Workflows

Git 기본

실행 순서

직접 해보기

헷갈리기 쉬운 것

관련 카드

용어 풀이