핵심 정리

git log --oneline --graph --decorate
git diff
git diff --staged

읽는 법

어떤 기록 읽기 명령을 먼저 떠올리면 되나

git log는 commit 객체 DAG를 시간 역순으로 순회하는 것이다

git log는 단순한 기록 열람이 아니라, commit 객체가 부모 포인터로 연결된 방향 비순환 그래프(DAG)를 HEAD에서 시작해 역방향으로 탐색합니다. --graph 옵션을 주면 이 DAG 구조가 터미널에 ASCII 아트로 시각화되어 브랜치가 어느 지점에서 갈라지고 merge되었는지 한눈에 파악됩니다. --decorate는 각 commit에 붙은 브랜치명·태그 등의 ref 이름을 함께 표시해 현재 HEAD와 원격 추적 브랜치의 위치 차이를 즉시 확인할 수 있게 합니다.

git log --oneline --graph --decorate     # 브랜치 구조 포함 압축 히스토리
git log --oneline -10                    # 최근 10개 커밋만
git log --author="Alice" --since="1 week ago"   # 필터링
git log main..feature/login --oneline    # feature에만 있는 커밋

git diff와 git diff --staged는 세 영역 중 서로 다른 구간을 비교한다

Git은 파일 상태를 세 영역으로 나눕니다. 작업 트리(실제 파일), 인덱스(스테이징 영역), 그리고 HEAD commit이 가리키는 tree 객체입니다. git diff는 작업 트리와 인덱스 사이의 차이, 즉 아직 git add하지 않은 변경을 보여 줍니다. git diff --staged는 인덱스와 HEAD commit 사이의 차이, 즉 다음 커밋에 들어갈 내용을 보여 줍니다. 두 명령을 함께 쓰면 "스테이징된 변경"과 "스테이징 대기 중인 변경"을 완전히 분리해 파악할 수 있습니다.

git diff                    # 작업 트리 → 인덱스 (add 안 된 변경)
git diff --staged           # 인덱스 → HEAD (add 된, 커밋 예정 변경)
git diff HEAD               # 작업 트리 → HEAD (전체 미커밋 변경)
git diff main..feature/login  # 두 브랜치 간 diff

git log는 시간 흐름을, git diff는 실제 줄 변화를 읽는 데 쓴다

누가 어떤 커밋을 언제 만들었는지 보고 싶으면 git log가 맞고, 지금 코드가 정확히 어떤 줄에서 어떻게 달라졌는지 보려면 git diff나 git show가 맞습니다. 커밋 메시지만 보면 "의도"만 보고 끝나기 쉽고, diff만 보면 전체 흐름을 놓치기 쉽습니다. 보통은 log로 범위를 좁히고 show나 diff로 실제 변경을 확인하는 순서가 가장 안전합니다.

커밋 내용을 git show로 확인해야 메시지와 실제 변경이 일치하는지 검증된다

커밋 메시지만 보고 내용을 판단하면 오해가 생깁니다. git show <SHA>는 해당 commit 객체의 메타데이터와 부모 commit과의 diff를 함께 출력해, 메시지와 실제 변경이 일치하는지 한번에 확인할 수 있습니다. 코드 리뷰나 버그 추적 시 "이 커밋이 정말 그 변경만 담고 있나"를 확인하는 가장 빠른 수단입니다. git log -p를 쓰면 전체 히스토리에 각 커밋의 diff를 붙여 출력할 수 있어 변경 흐름을 연속으로 읽을 때 유용합니다.

git show a1b2c3d             # 특정 커밋의 메타데이터 + diff
git log -p --follow -- src/auth.js  # 파일 이름 변경을 추적하며 diff 출력
git blame src/auth.js        # 각 줄이 어느 커밋에서 왔는지 확인

git add src/auth.js
git diff
# 출력 없음

git diff --staged
# 여기서만 실제 커밋 예정 변경이 보임

체크포인트

주의할 점