깃 명령어 정리

기본 설정

목적	명령어
사용자 이름 설정	`git config --global user.name "이름"`
사용자 이메일 설정	`git config --global user.email "이메일"`
설정 확인	`git config --list`

저장소 초기화 & 클론

목적	명령어
Git 저장소 초기화	`git init`
원격 저장소 클론	`git clone <url>`

작업 & 커밋

목적	명령어
변경 사항 확인	`git status`
변경 파일 추적 시작	`git add <파일>`
전체 파일 추가	`git add .`
커밋 생성	`git commit -m "메시지"`
커밋 수정 (메시지만)	`git commit --amend -m "수정된 메시지"`

브랜치

목적	명령어
브랜치 목록 확인	`git branch`
브랜치 생성	`git branch <브랜치명>`
브랜치 이동	`git checkout <브랜치명>`
브랜치 생성+이동	`git checkout -b <브랜치명>`
브랜치 삭제	`git branch -d <브랜치명>`

병합(Merge) & 충돌

목적	명령어
브랜치 병합	`git merge <브랜치명>`
병합 충돌 시 파일 수정 후 커밋	`git add <파일>` → `git commit`

원격 저장소 연결 & 동기화

목적	명령어
원격 저장소 추가	`git remote add origin <url>`
원격 저장소 확인	`git remote -v`
푸시	`git push origin <브랜치명>`
풀	`git pull origin <브랜치명>`
기본 브랜치 설정	`git push -u origin <브랜치명>`

되돌리기 & 리셋

목적	명령어
마지막 커밋만 취소 (변경사항은 보존)	`git reset --soft HEAD~1`
마지막 커밋+변경사항 되돌리기	`git reset --hard HEAD~1`
특정 파일 이전 상태로 복원	`git checkout HEAD <파일>`
특정 커밋으로 되돌림 (되돌린 커밋 추가됨)	`git revert <커밋ID>`

로그 & 기록

목적	명령어
커밋 로그 확인	`git log`
간단 로그	`git log --oneline`
브랜치 그래프 보기	`git log --oneline --graph --all`

정리 및 기타

목적	명령어
캐시된 파일 제거	`git rm --cached <파일>`
.gitignore 반영	`git rm -r --cached .` → `git add .` → `git commit -m ".gitignore 적용"`
임시 저장 (stash)	`git stash`
임시 저장 복원	`git stash pop`

실무에서 자주 쓰는 Git 명령어 TOP 10

git status

→ 지금 상태가 어떤지 확인하는 기본 중의 기본.

git add . + git commit -m "메시지"

→ 변경사항을 저장할 때. (자동화에서도 백그라운드로 항상 쓰이는 조합)

git log --oneline --graph --all

→ 브랜치가 꼬였나? 병합 어떻게 됐지? 시각적으로 확인할 수 있는 명령어.

git checkout -b <브랜치명>

→ 브랜치 새로 만들고 바로 이동.

git merge <브랜치명>

→ 작업 끝난 브랜치 병합할 때. 충돌 발생 여부도 여기서 나옴.

git pull origin <브랜치명>

→ 팀원 작업 최신 코드 가져올 때.

git push origin <브랜치명>

→ 내 작업을 원격으로 올릴 때.

git reset --hard HEAD~1

→ 잘못 커밋했을 때 되돌리기. 위험하지만 강력해.

git stash + git stash pop

→ 갑자기 다른 브랜치로 갈 일 있을 때, 변경사항 임시 저장.

git revert <커밋ID>

→ 실수로 올린 커밋 되돌릴 때, 이건 기록 남기면서 안전하게 되돌림.

실무에서 걸린 지점

1. `checkout`은 사실 위험한 다의어다

위 표를 보면 checkout이 두 번 나옵니다 — 브랜치 이동(git checkout <브랜치>)과 파일 되돌리기(git checkout HEAD <파일>). 전혀 다른 두 작업이 한 명령어에 얹혀 있어서, 브랜치명과 파일명이 겹치면 의도와 다른 쪽이 실행됩니다. 파일 복원 쪽은 작업 내용을 조용히 덮어쓰는 동작이라 특히 위험하고요. Git 2.23부터 이 문제 때문에 명령이 둘로 갈라졌습니다:

git switch <브랜치>          # 브랜치 이동 전용
git restore <파일>           # 파일 복원 전용 — 덮어쓰기 의도가 명시적

표의 checkout도 여전히 동작하지만, 새로 외운다면 switch/restore 쪽이 실수 여지가 적습니다.

2. `reset --hard`를 쓰려면 `reflog`부터 알아야 한다

TOP 10의 8번에 "위험하지만 강력해"라고 적어놨는데, 안전망을 함께 적지 않은 게 문제였습니다. --hard로 날린 커밋은 사라진 게 아니라 참조를 잃었을 뿐이고, git reflog에 HEAD의 이동 기록이 남아 있습니다:

git reflog                   # HEAD가 거쳐온 모든 지점
git reset --hard HEAD@{1}    # 날리기 직전으로 복귀

이걸 모르는 채로 --hard를 쓰는 것과 아는 채로 쓰는 것은 완전히 다른 일입니다. 그리고 원격에 이미 푸시한 커밋은 reset이 아니라 revert가 맞습니다 — 팀원의 히스토리를 다시 쓰게 만들지 않으니까요.

3. 표에 없지만 실제로 가장 값졌던 것 — 커밋 고고학 명령어

이력서와 회고를 쓰려고 2년치 커밋을 뒤질 때 실제로 일한 명령어는 표에 하나도 없었습니다:

git log -S "fetchAndMergeRoutes" --oneline   # 이 코드가 언제 들어오고 나갔나 (pickaxe)
git log --oneline -- src/store/              # 이 디렉터리를 건드린 커밋만
git blame -L 30,40 <파일>                     # 이 줄을 마지막으로 바꾼 커밋

-S(pickaxe)는 특정 문자열이 추가되거나 삭제된 커밋만 골라줍니다. "이 함수가 언제 생겼지 / 언제 사라졌지"에 대한 답이라, 블로그 글의 날짜 오류를 커밋 근거로 교정하는 작업도 전부 이걸로 했어요. 치트시트는 "오늘 쓸 명령어" 위주로 만들게 되지만, 시간이 지나 값진 건 과거를 심문하는 명령어 쪽이었습니다.

커밋을 어떻게 남길지는 커밋 메시지 작성법에 따로 정리했습니다 — 여기의 고고학 명령어들이 잘 동작하려면 결국 커밋이 잘 쪼개져 있어야 하더라고요.