Git 기초 실습 예시
Git의 기본 흐름(add → commit)을 시나리오로 익히는 가이드 | ← 매뉴얼로 돌아가기
대상 Git 버전2.40 이상 (최신 2.54.0 기준)
이 파일의 목적매뉴얼을 보완하는 실습·교육용 시나리오 예시집
매뉴얼 문서Git_Basics_Manual.html — 각 시나리오에서 링크로 연결됩니다
작성일2026년 6월 13일
● 초급
처음 시작하기
저장소를 만들고 첫 커밋을 남기는 가장 기본적인 흐름
G-1
초급
새 프로젝트를 만들고 첫 커밋 남기기
바이브코딩으로 만든 작은 웹페이지 폴더(
my-site)가 있습니다. 이제부터 변경 이력을 남기고 싶어 Git을 처음 적용합니다. 작업 대상은 이 my-site 폴더입니다.
단계별 실행
- (최초 1회) 내 이름·이메일 설정
커밋에 작성자로 기록됩니다. 컴퓨터에서 한 번만 하면 됩니다.
- 프로젝트 폴더로 이동해 저장소 초기화
git init이.git폴더를 만들어 추적을 시작합니다. - 상태 확인
아직 추적되지 않은(빨간색) 파일들이 보입니다.
- 전부 스테이징하고 커밋
첫 버전이 저장소에 기록됩니다.
git config --global user.name "Hong Gildong" git config --global user.email "you@example.com" cd ~/projects/my-site git init -b main git status git add . git commit -m "프로젝트 첫 커밋"
빈 저장소에 첫 버전이 만들어집니다. 이제
git log --oneline을 치면 방금 만든 커밋 하나가 보입니다. 앞으로 모든 변경은 이 첫 커밋 위에 쌓입니다.막히면 언제든
git status를 치세요. 지금 무엇이 스테이징됐고 다음에 뭘 하면 되는지 Git이 안내해 줍니다.
G-2
초급
파일을 고치고 두 번째 커밋 남기기
G-1에서 첫 커밋을 마친 뒤,
index.html의 제목을 수정했습니다. 이 변경을 새로운 버전으로 기록하려 합니다.
사용 명령어
단계별 실행
- 무엇이 바뀌었는지 확인
status로 수정된 파일을,diff로 구체적인 변경 줄을 봅니다. - 변경을 스테이징
커밋에 담을 파일을
add로 올립니다. - 의미 있는 메시지로 커밋
무엇을 왜 바꿨는지 한 줄로 적습니다.
git status git diff # 어떤 줄이 바뀌었는지 확인 git add index.html git commit -m "메인 페이지 제목 문구 수정" git log --oneline # 커밋이 2개로 늘어남
커밋 전
git diff로 변경을 눈으로 확인하면 실수를 크게 줄일 수 있습니다. 추적 중인 파일만 고쳤다면 git commit -am "메시지"로 add와 commit을 한 번에 할 수도 있습니다.커밋 단위는 '한 가지 주제'로 잡으세요. 제목 수정과 새 기능 추가를 한 커밋에 섞지 말고 나누면 이력이 읽기 쉽습니다.
G-3
초급
불필요한 파일을 .gitignore로 제외하기
프로젝트에 비밀 키가 담긴
.env 파일과 macOS가 만든 .DS_Store가 생겼습니다. 이런 파일은 저장소에 올리면 안 됩니다. 추적 대상에서 제외합니다.
사용 명령어
단계별 실행
- 저장소 루트에 .gitignore 생성
제외할 패턴을 한 줄에 하나씩 적습니다.
- status로 제외 확인
.env·.DS_Store가 목록에서 사라졌는지 봅니다. - .gitignore 자체를 커밋
이 규칙을 팀과 공유하려면 .gitignore도 버전 관리에 넣습니다.
printf ".env\n.DS_Store\nnode_modules/\n" > .gitignore git status # 제외된 파일은 더 이상 안 보임 git add .gitignore git commit -m ".gitignore 추가: 비밀 파일·잡파일 제외"
.gitignore는 아직 추적 안 된 파일에만 효과가 있습니다. 이미 실수로 커밋한 .env가 있다면 git rm --cached .env로 추적을 푼 뒤 커밋해야 합니다.
● 중급
스테이징을 다루기
변경을 골라 담고, 잘못 담은 것을 빼고, 이력을 읽는 단계
D-1
중급
한꺼번에 수정한 것 중 일부만 골라 커밋
작업하다 보니 '회원가입 기능'과 '관계없는 오타 수정'을 한 번에 건드렸습니다. 두 가지를 별도 커밋으로 깔끔하게 나누고 싶습니다.
사용 명령어
단계별 실행
- 회원가입 관련 파일만 add
git add .대신 파일을 콕 집어 올립니다. - 첫 번째 주제로 커밋
- 나머지(오타) 파일을 add 하고 따로 커밋
git status git add signup.js auth.js git commit -m "회원가입 폼 검증 추가" git add README.md git commit -m "README 오타 수정"
한 파일 안에서도 변경 덩어리별로 나눠 담고 싶으면
git add -p를 쓰세요. 각 덩어리마다 담을지(y/n) 물어봅니다.
D-2
중급
실수로 add 한 파일을 커밋 전에 빼기
git add .을 했더니 커밋하면 안 되는 큰 임시 파일까지 스테이징됐습니다. 커밋하기 전에 그 파일만 스테이징에서 내리고 싶습니다.
사용 명령어
단계별 실행
- status로 스테이징 목록 확인
- 해당 파일만 스테이징에서 내리기
파일의 수정 내용은 그대로 두고 '커밋 후보'에서만 제외합니다.
- 나머지만 커밋
git status git restore --staged big_temp.zip # 스테이징에서만 내림(파일은 그대로) git commit -m "본 작업 커밋"
git restore --staged <파일>은 git reset <파일>과 같은 '스테이징 취소'입니다. 파일 내용은 건드리지 않고 add만 되돌립니다. 되돌리기 전반은 되돌리기·복구 매뉴얼을 참고하세요.
D-3
중급
지나간 이력을 읽고 특정 변경 찾아보기
"이 버튼 색을 누가 언제 바꿨지?"가 궁금합니다. 커밋 이력을 다양한 방식으로 살펴봅니다.
단계별 실행
- 간략 이력 보기
--oneline으로 커밋을 한 줄씩 훑습니다. - 특정 파일의 변경 이력만 보기
- 두 커밋 사이의 차이 보기
커밋 ID 앞 7자리만 적어도 됩니다.
git log --oneline --graph git log --oneline -- button.css # 특정 파일의 이력만 git show a1b2c3d # 특정 커밋의 상세 변경 git diff a1b2c3d HEAD # 그 커밋과 현재의 차이
커밋 ID(해시)는 길지만 앞 7자리 정도만 적어도 Git이 알아서 찾습니다. 누가 각 줄을 마지막으로 바꿨는지는
git blame <파일>로 봅니다.
● 고급
좋은 이력 만들기
읽기 좋은 커밋 단위와 메시지로 협업에 강한 이력을 설계
P-1
고급
큰 변경을 의미 단위 커밋으로 쪼개기
AI 도구로 한 파일에 여러 기능을 한꺼번에 생성했습니다. 그대로 한 커밋으로 묶으면 나중에 일부만 되돌리기 어렵습니다. 변경 덩어리별로 나눠 커밋합니다.
단계별 실행
- 대화식으로 덩어리 선택
add -p가 변경을 조각내어 담을지 묻습니다(y/n/s 등). - 담은 것만 검토 후 커밋
diff --staged로 이번 커밋 범위를 확인합니다. - 남은 덩어리로 다음 커밋 반복
git add -p app.js # 덩어리마다 y/n 선택 git diff --staged # 담긴 범위 확인 git commit -m "기능 A: 입력 검증" git add -p app.js git commit -m "기능 B: 결과 캐싱"
add -p의 선택지: y(담기) n(건너뛰기) s(더 잘게 쪼개기) q(종료). 잘 모르면 ?로 도움말을 봅니다.
P-2
고급
협업을 염두에 둔 깔끔한 이력 설계
곧 이 프로젝트를 GitHub에 올려 팀과 공유할 예정입니다. 동료가 이력만 봐도 변경 흐름을 이해할 수 있도록 커밋을 정돈합니다.
사용 명령어
단계별 실행
- 현재 이력 점검
"수정", "ㅁㄴㅇ" 같은 의미 없는 커밋이 있는지 봅니다.
- 아직 공유 전이라면 마지막 몇 개를 하나로 합치기
reset --soft로 커밋만 풀고 변경은 스테이징에 남깁니다. - 제대로 된 메시지로 다시 커밋
git log --oneline git reset --soft HEAD~3 # 최근 3개 커밋을 풀어 스테이징으로(변경은 보존) git commit -m "회원가입 기능 구현 (폼·검증·에러 처리)"
이렇게 이력을 다시 쓰는 작업은 아직 GitHub에 올리지 않은(공유 전) 커밋에만 하세요. 이미 push해 남들이 받아 간 커밋을 고치면 협업에 충돌이 생깁니다. 자세한 안전 규칙은 되돌리기·복구 매뉴얼에 있습니다.
Git 2.54.0 기준 · 2026년 6월 13일 작성
← Git 기초 매뉴얼 |
브랜치 실습 →