Git 명령어 치트시트
자주 쓰는 Git 명령어를 카테고리별로 요약 정리했습니다. 실무에서 바로 복사해 사용하세요.
설정(Config)
| 명령어 | 설명 | |
|---|---|---|
git config --global user.name "이름" | 커밋에 사용할 사용자 이름 설정 | |
git config --global user.email "이메일" | 커밋에 사용할 이메일 설정 | |
git config --global core.editor vim | 기본 에디터 설정 | |
git config --list | 설정된 항목 전체 확인 |
저장소 시작(Init / Clone)
| 명령어 | 설명 | |
|---|---|---|
git init | 현재 디렉토리를 Git 저장소로 초기화 | |
git clone <url> | 원격 저장소를 로컬에 복제 | |
git clone <url> <폴더명> | 지정한 폴더명으로 복제 |
기본 작업(Add / Commit / Status)
| 명령어 | 설명 | |
|---|---|---|
git status | 작업 디렉토리와 스테이징 영역 상태 확인 | |
git add <파일> | 특정 파일을 스테이징 | |
git add . | 현재 디렉토리의 모든 변경사항을 스테이징 | |
git commit -m "메시지" | 스테이징된 변경사항 커밋 | |
git commit -am "메시지" | 추적 중인 파일을 add 후 한 번에 커밋 | |
git commit --amend주의 | 직전 커밋 메시지/내용 수정 |
브랜치(Branch)
| 명령어 | 설명 | |
|---|---|---|
git branch | 로컬 브랜치 목록 확인 | |
git branch -a | 원격 포함 모든 브랜치 확인 | |
git branch <이름> | 새 브랜치 생성 | |
git checkout <이름>주의 | 브랜치 전환 | |
git checkout -b <이름>주의 | 브랜치 생성 후 바로 전환 | |
git switch <이름>주의 | 브랜치 전환(신규 명령) | |
git switch -c <이름>주의 | 브랜치 생성 후 전환(신규 명령) | |
git branch -d <이름> | 브랜치 삭제(머지된 경우) | |
git branch -D <이름>파괴적 | 브랜치 강제 삭제 |
머지ㆍ리베이스(Merge / Rebase)
| 명령어 | 설명 | |
|---|---|---|
git merge <브랜치> | 지정 브랜치를 현재 브랜치에 머지 | |
git merge --no-ff <브랜치> | fast-forward 없이 머지 커밋 생성 | |
git rebase <브랜치>주의 | 현재 브랜치를 지정 브랜치 위로 리베이스 | |
git rebase -i HEAD~3주의 | 최근 3개 커밋을 인터랙티브 리베이스 | |
git rebase --abort주의 | 리베이스 중단ㆍ취소 | |
git merge --abort | 머지 중단ㆍ취소 |
원격 저장소(Remote / Push / Pull)
| 명령어 | 설명 | |
|---|---|---|
git remote -v | 원격 저장소 목록 확인 | |
git remote add origin <url> | 원격 저장소 추가 | |
git remote set-url origin <url> | 원격 저장소 URL 변경 | |
git fetch | 원격의 변경사항만 가져오기(머지 안 함) | |
git pull | 원격 변경사항 가져와 현재 브랜치에 머지 | |
git pull --rebase주의 | pull 시 머지 대신 리베이스 | |
git push | 현재 브랜치를 원격에 푸시 | |
git push -u origin <브랜치> | 브랜치 첫 푸시 + 추적 설정 | |
git push --force-with-lease주의 | 안전한 강제 푸시(다른 사람 커밋 보호) |
되돌리기(Reset / Revert / Restore)
| 명령어 | 설명 | |
|---|---|---|
git restore <파일> | 작업 디렉토리 변경사항 취소 | |
git restore --staged <파일> | 스테이징 취소 | |
git reset HEAD~1주의 | 직전 커밋 취소(변경사항은 유지) | |
git reset --soft HEAD~1주의 | 커밋만 취소, 변경사항은 스테이징 유지 | |
git reset --hard HEAD~1파괴적 | 커밋과 변경사항 모두 폐기(주의) | |
git revert <커밋>주의 | 지정 커밋을 취소하는 새 커밋 생성 |
스태시(Stash)
| 명령어 | 설명 | |
|---|---|---|
git stash | 현재 변경사항을 임시 저장하고 작업 디렉토리 정리 | |
git stash -u | 추적되지 않는 파일까지 스태시 | |
git stash list | 스태시 목록 확인 | |
git stash pop | 가장 최근 스태시를 적용하고 목록에서 제거 | |
git stash apply | 스태시 적용(목록에 유지) | |
git stash drop파괴적 | 스태시 제거 |
로그ㆍ히스토리(Log / Diff)
| 명령어 | 설명 | |
|---|---|---|
git log | 커밋 히스토리 확인 | |
git log --oneline | 한 줄 요약 로그 | |
git log --graph --oneline --all | 모든 브랜치 그래프 보기 | |
git diff | 작업 디렉토리와 스테이징 차이 | |
git diff --staged | 스테이징과 마지막 커밋 차이 | |
git blame <파일> | 파일의 줄별 마지막 수정자 확인 | |
git show <커밋> | 특정 커밋의 변경 내용 확인 |
태그(Tag)
| 명령어 | 설명 | |
|---|---|---|
git tag | 태그 목록 확인 | |
git tag <이름> | 경량 태그 생성 | |
git tag -a <이름> -m "메시지" | 주석 태그 생성 | |
git push origin <태그> | 특정 태그 푸시 | |
git push origin --tags | 모든 태그 푸시 | |
git tag -d <이름>파괴적 | 로컬 태그 삭제 |
헷갈리는 Git 명령어 비교
이름이나 결과가 비슷해 보이지만 실제 동작ㆍ안전성이 달라 실무에서 자주 혼동되는 명령어들을 한눈에 정리했습니다. 특히 공유 브랜치에서 작업할 때 잘못 선택하면 동료 커밋을 망가뜨릴 수 있으므로 주의하세요.
원격 저장소ㆍCIㆍAPI 연동에서 나오는 401ㆍ403ㆍ500 같은 응답은 HTTP 상태코드 정리표에서 의미를 바로 대조할 수 있습니다. 릴리스 노트나 README 예시 코드를 정리할 때는 HTMLㆍCSSㆍJS 포매터와 JSON 포매터ㆍ변환기도 같이 쓰면 커맨드 출력과 설정 파일을 읽기 좋게 맞출 수 있습니다.
1. git merge vs git rebase
두 브랜치의 변경사항을 합치는 작업이지만, 히스토리를 다루는 방식이 완전히 다릅니다.
| 구분 | git merge | git rebase |
|---|---|---|
| 히스토리 모양 | 분기ㆍ합류가 그대로 남는 그래프 | 직선으로 재작성 |
| 머지 커밋 | 생성(기본) | 생성 안 함 |
| 커밋 SHA | 유지 | 재작성(변경) |
| 공유 브랜치 | ✅ 안전 | ⚠️ 푸시된 커밋 리베이스는 금지 |
| 언제 쓰나 | feature → main 등 공식 통합 | 개인 브랜치 정리, main 위로 올리기 |
결론: 공유된 브랜치 통합은 merge, 개인 작업 브랜치 정리ㆍ업데이트는 rebase. 이미 푸시한 커밋을 리베이스하면 커밋 SHA 가 바뀌어 동료와 충돌이 생기므로 절대 금지입니다.
2. git reset vs git revert
둘 다 "커밋을 되돌린다"는 느낌이지만, 히스토리를 건드리는지 여부가 다릅니다.
| 구분 | git reset | git revert |
|---|---|---|
| 동작 방식 | HEAD 포인터를 과거 커밋으로 이동(히스토리 삭제) | 변경을 취소하는 새 커밋을 추가(히스토리 보존) |
| 커밋 이력 | 사라짐 | 그대로 남음 + 취소 커밋 추가 |
| 공유 브랜치 | ⚠️ 강제 푸시 필요, 위험 | ✅ 안전(일반 푸시로 OK) |
| 언제 쓰나 | 아직 푸시하지 않은 로컬 커밋 정리 | 이미 푸시된 커밋을 안전하게 취소 |
결론: 혼자 쓰는 로컬이라면 reset이 깔끔하지만, 공유 브랜치에서는 무조건 revert. reset --hard 후 강제 푸시는 동료 작업을 날릴 수 있는 가장 위험한 시나리오입니다.
3. git pull vs git fetch
원격 저장소의 변경사항을 가져온다는 점은 같지만, 자동 머지 여부가 다릅니다.
| 구분 | git fetch | git pull |
|---|---|---|
| 원격 변경 가져오기 | ✅ | ✅ |
| 현재 브랜치에 머지 | ❌ 수동 | ✅ 자동(fetch + merge) |
| 예상치 못한 머지 커밋 | 없음 | 발생 가능 |
| 언제 쓰나 | 원격 상태만 확인, 머지 전 검토 | 빠르게 동기화하고 작업 이어가기 |
결론: pull = fetch + merge. 안전하게 가려면 git fetch 후 git log origin/main..HEAD 등으로 차이를 확인하고 수동 머지. 리베이스 기반 워크플로우라면 git pull --rebase 를 기본으로 설정하는 것도 좋습니다.
4. git reset --soft vs --mixed vs --hard
같은 reset 명령이라도 옵션에 따라 "어디까지 되돌릴지"가 완전히 달라집니다.
| 옵션 | HEAD | 스테이징 | 작업 디렉토리 | 언제 |
|---|---|---|---|---|
--soft | 이동 | 유지 | 유지 | 커밋만 취소하고 메시지 다시 쓰기 |
--mixed(기본) | 이동 | 초기화 | 유지 | 스테이징만 풀고 변경사항은 보존 |
--hard | 이동 | 초기화 | 초기화 ⚠️ | 완전히 과거 상태로 - 변경사항 모두 폐기 |
결론: --hard는 작업 디렉토리의 변경사항까지 날리므로 반드시 git status로 상태 확인 후 사용. 실수로 날렸다면 git reflog로 복구 가능한 경우가 있습니다.
5. git stash pop vs git stash apply
스태시에 저장해둔 변경사항을 다시 꺼낼 때 쓰는 두 명령의 차이는 "스태시 목록에서 제거되는지"입니다.
| 구분 | git stash pop | git stash apply |
|---|---|---|
| 변경사항 복원 | ✅ | ✅ |
| 스태시 목록 | 제거 | 유지 |
| 여러 브랜치에 재사용 | 불가(1회성) | 가능 |
| 언제 쓰나 | 한 번만 적용하고 끝낼 때 | 같은 변경을 여러 곳에 적용하거나 테스트할 때 |
결론: 확실하게 "이 스태시 이제 필요 없음"이 아니라면 apply가 안전합니다. pop이 충돌을 일으키면 변경사항은 복원되지만 스태시는 이미 제거되어 있을 수 있으므로, 중요한 스태시는 항상 apply → 확인 → 수동 drop 순서를 권장합니다.
🧭 이럴 때 무슨 명령어? (시나리오 인덱스)
- 방금 한 커밋 메시지를 고치고 싶다 →
git commit --amend -m "새 메시지"(푸시 전에만) - 커밋은 했는데 푸시는 아직, 마지막 커밋을 통째로 취소 →
git reset --soft HEAD~1(변경사항 유지) - 이미 푸시한 커밋을 안전하게 되돌리기 →
git revert <커밋>(히스토리 보존) - 지금 작업을 잠깐 치워두고 다른 브랜치 가야 함 →
git stash -u→ 작업 후 →git stash pop - 새 브랜치 만들고 바로 이동 →
git switch -c <이름> - 로컬 브랜치를 원격에 처음 푸시 →
git push -u origin <브랜치> - 원격 main의 최신 변경을 내 브랜치 위로 끌어오기 →
git fetch origin && git rebase origin/main - 실수로 머지 시작했는데 취소 →
git merge --abort - 리베이스 도중 꼬였을 때 원위치 →
git rebase --abort - 강제 푸시는 해야 하는데 동료 커밋은 보호하고 싶다 →
git push --force-with-lease - 특정 파일만 직전 커밋 상태로 복구 →
git restore <파일> - 지운 브랜치/커밋 복구 →
git reflog로 SHA 찾고 →git checkout <sha> - 누가 이 줄을 마지막으로 고쳤지? →
git blame <파일> - 릴리스 v1.2.0 태그 만들고 푸시 →
git tag -a v1.2.0 -m "release"→git push origin v1.2.0
Git의 기본 흐름은 작업 디렉토리(Working Directory) → 스테이징 영역(Staging Area) → 로컬 저장소(Local Repository) → 원격 저장소(Remote Repository) 순으로 변경사항이 이동합니다.
git add- 작업 디렉토리의 변경사항을 스테이징 영역으로 이동git commit- 스테이징 영역의 변경사항을 로컬 저장소에 기록git push- 로컬 저장소의 커밋을 원격 저장소로 업로드git pull- 원격 저장소의 변경사항을 로컬로 가져와 머지
핵심 개념 간단 설명
머지ㆍ리베이스ㆍ리셋ㆍ리버트ㆍfetch vs pull은 위 비교표에서 다뤘고, 여기서는 표에 없는 개념만 정리합니다.
- 브랜치(Branch) - 메인 작업 흐름에서 갈라져 나온 독립된 작업 공간입니다. 새 기능 개발이나 실험을 본 코드에 영향 없이 진행할 수 있습니다.
- 스태시(Stash) - 아직 커밋하지 않은 작업을 임시 서랍에 잠깐 넣어두는 기능입니다. 급하게 다른 브랜치로 이동해야 할 때 현재 변경사항을 잃지 않고 보관했다가 나중에 꺼내 이어서 작업할 수 있습니다.
- HEAD - 현재 작업 중인 브랜치의 가장 최신 커밋을 가리키는 포인터입니다.
HEAD~1은 직전 커밋,HEAD~3은 3개 전 커밋을 의미합니다. - 패스트 포워드(Fast-forward) - 머지 시 분기점 이후 한쪽에만 새 커밋이 있을 때, 새로운 머지 커밋을 만들지 않고 브랜치 포인터만 앞으로 이동시키는 방식입니다.
- 태그(Tag) - 특정 커밋에 의미 있는 이름표(주로 버전 번호)를 붙이는 기능입니다. 릴리스 지점을 표시하는 데 주로 사용됩니다.
자주 묻는 질문
git fetch와 git pull의 차이는 무엇인가요?
fetch는 원격의 변경사항을 가져오기만 하고, pull은 가져온 후 자동으로 현재 브랜치에 머지합니다. pull = fetch + merge로 이해하면 됩니다.
git reset과 git revert의 차이는 무엇인가요?
reset은 커밋 이력 자체를 되돌려 히스토리를 변경하고, revert는 변경을 취소하는 새 커밋을 추가해 히스토리를 보존합니다. 공유 브랜치에서는 revert를 권장합니다.
merge와 rebase 중 무엇을 써야 하나요?
merge는 히스토리를 그대로 보존하고, rebase는 깔끔한 직선 히스토리를 만듭니다. 공개된 브랜치는 merge, 개인 브랜치는 rebase가 일반적입니다.
실수로 푸시한 커밋을 되돌리려면?
이미 공유된 브랜치라면 git revert로 취소 커밋을 추가하세요. git reset --hard 후 강제 푸시는 동료 작업을 망가뜨릴 수 있어 위험합니다.
git switch와 git checkout 중 무엇을 써야 하나요?
최신 Git에서는 브랜치 전환은 git switch, 파일 복구는 git restore로 분리되어 더 명확합니다. checkout은 호환을 위해 남아 있지만 새 코드에서는 switch/restore를 권장합니다.