git add와 git commit의 정확한 역할과 옵션을 배운다. Staging Area를 활용해 커밋을 논리적으로 분리하는 방법, 좋은 커밋 메시지를 작성하는 원칙을 이해한다.
add → commit — Git의 기본 작업 단위
파일을 저장하는 것과 Git에 기록하는 것은 다릅니다. 파일을 수정하면 Working Directory에만 변경이 생깁니다. git add로 Staging Area에 올리고, git commit으로 비로소 이력에 영구 기록됩니다.
git status — 현재 상태 파악
add와 commit을 배우기 전에 git status를 익혀야 합니다. 현재 어떤 파일이 어떤 상태인지 알 수 있습니다.
git status
# 출력 예시:
On branch main
Changes to be committed: ← Staged (add 완료)
(use "git restore --staged ..." to unstage)
new file: README.md
modified: src/index.js
Changes not staged for commit: ← Modified (수정됐지만 add 안 함)
(use "git add ..." to update what will be committed)
modified: src/utils.js
Untracked files: ← 새 파일, Git이 모름
(use "git add ..." to include in what will be committed)
config.json
# 짧은 버전
git status -s
# M src/index.js ← Staged modified
# M src/utils.js ← Unstaged modified
# ?? config.json ← Untracked
git add — Staging Area에 올리기
# 특정 파일
git add README.md
git add src/index.js
# 특정 디렉토리 전체
git add src/
# 모든 변경 파일 (신규, 수정, 삭제 모두)
git add .
git add -A
# 수정·삭제만 (신규 Untracked 파일 제외)
git add -u
# 대화형 — 파일 내 변경 블록(hunk) 단위로 선택
git add -p
git add --patch
git add -p — 부분 스테이징의 힘
-p 옵션은 하나의 파일 안에서도 특정 변경 블록만 선택해 스테이징할 수 있습니다. 한 파일에서 버그 수정과 기능 추가를 동시에 했을 때 두 개의 커밋으로 분리하는 데 사용합니다.
git add -p src/app.js
# 각 hunk마다 선택:
# y: 이 변경 포함
# n: 이 변경 제외
# s: 더 작은 hunk로 분할
# e: 직접 편집
# q: 종료
git commit — 이력에 기록
# 에디터 열어서 메시지 작성
git commit
# 인라인 메시지
git commit -m "feat: 로그인 기능 추가"
# 제목 + 본문
git commit -m "feat: 로그인 기능 추가
- JWT 기반 인증 구현
- 세션 만료 처리 추가
- 에러 메시지 한국어화"
# add + commit 한 번에 (Tracked 파일만, Untracked 제외)
git commit -am "fix: 타입 오류 수정"
# Staging Area 내용을 직전 커밋에 합치기 (이력 수정!)
git commit --amend
git commit --amend -m "새 메시지" # 메시지만 변경
# 주의: 이미 push한 커밋은 amend하면 안 됨
좋은 커밋 메시지 — 협업의 핵심
커밋 메시지는 코드가 왜 이렇게 변경되었는지를 기록합니다. 6개월 후의 나 혹은 팀원이 git log를 볼 때 이해할 수 있어야 합니다.
# 나쁜 커밋 메시지 예시
"수정"
"fix bug"
"asdf"
"작업중"
# 좋은 커밋 메시지 예시
"feat: 비밀번호 재설정 이메일 발송 기능 추가"
"fix: 로그인 시 토큰 만료 체크 누락 수정"
"refactor: 사용자 인증 로직 별도 함수로 분리"
"docs: README에 환경 설정 방법 추가"
Conventional Commits 규칙
팀에서 가장 널리 쓰이는 커밋 메시지 규칙입니다.
형식: type(scope): 제목
type 종류:
feat → 새 기능 추가
fix → 버그 수정
docs → 문서 변경
style → 코드 포맷팅 (로직 변경 없음)
refactor → 리팩터링 (기능 변경 없음)
test → 테스트 추가/수정
chore → 빌드, 의존성, 설정 변경
perf → 성능 개선
ci → CI/CD 설정 변경
예시:
feat(auth): Google OAuth 로그인 추가
fix(api): 상품 목록 페이지네이션 오프셋 계산 오류 수정
refactor(user): UserService 메서드 단일 책임 원칙 적용
docs: API 엔드포인트 문서 업데이트
커밋 메시지 작성 7가지 원칙
1. 제목은 50자 이내
2. 제목과 본문 사이 빈 줄 하나
3. 본문은 72자에서 줄바꿈
4. 제목 끝에 마침표 없음
5. 명령형으로 작성 ("추가했다" 아닌 "추가")
6. What이 아닌 Why를 설명 (무엇은 diff에서 보임)
7. 이슈 번호 연결: "Fixes #42" 또는 "Closes #42"
스테이징 취소와 변경 되돌리기
# Staged → Unstaged (커밋 전 취소)
git restore --staged README.md # 특정 파일
git restore --staged . # 전체
# Working Directory 변경 취소 (수정 전 상태로)
git restore README.md # 위험! 수정 내용 영구 삭제
# 구식 방법 (같은 동작)
git reset HEAD README.md # unstage
git checkout -- README.md # 수정 취소
관련 검색어 · git add commit 차이, git status 보는법, 좋은 커밋 메시지, Conventional Commits, git add -p, git commit amend