Lesson 4

add·commit의 흐름

4 min Views 1

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

채용정보
공지사항
인사이트
MY