Git 명령어 치트시트
자주 쓰는 Git 명령어를 카테고리별로 요약 정리했습니다. 실무에서 바로 복사해 사용하세요.
🤔 헷갈리는 Git 명령어 비교
이름이나 결과가 비슷해 보이지만 실제 동작·안전성이 달라 실무에서 자주 혼동되는 명령어들을 한눈에 정리했습니다. 특히 공유 브랜치에서 작업할 때 잘못 선택하면 동료 커밋을 망가뜨릴 수 있으므로 주의하세요.
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 워크플로우 · 핵심 개념 한눈에
Git의 기본 흐름은 작업 디렉토리(Working Directory) → 스테이징 영역(Staging Area) → 로컬 저장소(Local Repository) → 원격 저장소(Remote Repository) 순으로 변경사항이 이동합니다.
git add- 작업 디렉토리의 변경사항을 스테이징 영역으로 이동git commit- 스테이징 영역의 변경사항을 로컬 저장소에 기록git push- 로컬 저장소의 커밋을 원격 저장소로 업로드git pull- 원격 저장소의 변경사항을 로컬로 가져와 머지
핵심 개념 간단 설명
- 브랜치(Branch) - 메인 작업 흐름에서 갈라져 나온 독립된 작업 공간입니다. 새 기능 개발이나 실험을 본 코드에 영향 없이 진행할 수 있습니다.
- 머지(Merge) - 두 브랜치의 변경사항을 합치는 작업입니다. 양쪽 히스토리가 모두 보존되며 새로운 머지 커밋이 생성될 수 있습니다.
- 리베이스(Rebase) - 내 브랜치의 커밋들을 떼어내서 다른 브랜치의 최신 커밋 위에 다시 쌓는 작업입니다. 머지와 결과는 비슷하지만 히스토리가 직선으로 깔끔해집니다. 단, 이미 공유된 커밋을 리베이스하면 다른 사람과 충돌이 생기므로 주의해야 합니다.
- 스태시(Stash) - 아직 커밋하지 않은 작업을 임시 서랍에 잠깐 넣어두는 기능입니다. 급하게 다른 브랜치로 이동해야 할 때 현재 변경사항을 잃지 않고 보관할 수 있고, 나중에 꺼내서 이어서 작업할 수 있습니다.
- 체크아웃(Checkout) / 스위치(Switch) - 다른 브랜치나 특정 커밋 시점으로 이동하는 작업입니다. 최근에는 더 명확한
git switch(브랜치 전환)와git restore(파일 복구)로 분리되었습니다. - 리셋(Reset) - 커밋을 과거 시점으로 되돌리는 작업입니다. 히스토리 자체를 변경하므로 공유된 브랜치에서는 위험합니다.
--soft는 변경사항 유지,--hard는 모두 폐기입니다. - 리버트(Revert) - 특정 커밋의 변경사항을 취소하는 새 커밋을 만들어 추가합니다. 히스토리를 보존하므로 공유 브랜치에서 안전하게 되돌리는 표준 방법입니다.
- 페치(Fetch) vs 풀(Pull) - fetch는 원격의 변경사항을 가져오기만 하고, pull은 가져온 뒤 자동으로 현재 브랜치에 머지합니다.
pull = fetch + merge로 이해하면 됩니다. - 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를 권장합니다.