Quick Flow

git add <file>
git commit -m "의도를 설명하는 메시지"
git push

기본 흐름

어떤 기본 흐름을 먼저 떠올리면 되나

스테이징은 커밋 내용을 정확히 제어하는 유일한 수단이다

Git은 수정한 파일을 자동으로 커밋하지 않습니다. 반드시 git add로 스테이징 영역(index)에 올려야 다음 커밋에 포함됩니다. 이 설계의 핵심 이점은 하나의 작업 세션에서 여러 변경을 했을 때, 논리적으로 관련된 파일만 선택해 커밋을 분리할 수 있다는 점입니다. git add .는 실행한 현재 디렉터리와 하위 경로를 stage하므로, 저장소 root에서 실행하면 의도하지 않은 디버그 코드·임시 파일도 같이 들어가기 쉽습니다.

git add src/auth.js          # 특정 파일만 스테이징
git add src/                 # 디렉터리 단위
git add -p                   # 줄(hunk) 단위로 선택해 스테이징
git status                   # 스테이징 결과 확인

커밋은 blob/tree/commit 객체로 저장되는 스냅샷이다

git commit은 단순히 파일을 저장하는 것이 아닙니다. Git은 index의 파일 내용을 blob 객체로, 디렉터리 구조를 tree 객체로, 작성자·시간·부모 commit ID·message를 담은 commit 객체로 기록합니다. object ID의 hash algorithm은 repository format에 따라 다르며, commit은 이전 상태와의 patch가 아니라 그 시점 tree를 가리킵니다. message에 무엇보다 왜를 남기면 나중에 git log나 git blame으로 맥락을 파악하기 쉽습니다.

git commit -m "Fix null check in auth token validation"
# 좋은 예: 이유가 드러남

git commit -m "Fix bug"
# 나쁜 예: 나중에 어떤 버그인지 알 수 없음

push는 로컬 커밋을 원격 ref로 전송하고 상대방이 fetch할 수 있게 만든다

git push는 로컬 브랜치의 커밋 객체들을 원격 저장소에 전송하고, 원격의 해당 브랜치 ref를 갱신합니다. Git은 원격에 없는 객체만 전송하므로 이미 공유된 커밋은 다시 보내지 않습니다. 처음 push하는 브랜치라면 -u 옵션으로 원격 추적 브랜치를 설정해야 이후 git push, git pull을 인자 없이 쓸 수 있습니다.

git push -u origin feature/login   # 처음 push: 원격 추적 브랜치 설정
git push                           # 이후 push: 인자 생략 가능

git add <file>과 git add .는 편의성과 통제력의 교환이다

작업이 작고 한 파일에 집중되어 있으면 git add <file>이 가장 안전합니다. 반대로 한 번에 정리된 작은 작업을 끝냈다면 git add .가 빠릅니다. 문제는 .env, 빌드 산출물, 디버그 로그처럼 커밋되면 안 되는 파일까지 같이 들어가기 쉽다는 점입니다. 범위가 넓을수록 git add .보다 파일 지정 또는 git add -p가 더 안전합니다.

git add src/auth.js
git commit -m "Fix auth token parsing"

# 빠르지만 범위를 넓게 잡음
git add .
git status
git diff --staged

체크포인트

주의할 점

# 첫 push
git push -u origin feature/login

# 이후 같은 브랜치에서는
git push