Git 초보자 필수 명령어 20개 — 개념부터 실수 복구까지
Git은 처음 배울 때 낯선 용어와 명령어가 잔뜩 쏟아져 혼란스럽습니다. 하지만 실제로 90%의 작업은 10개 남짓한 명령어로 처리됩니다. 이 글은 Git을 처음 쓰는 개발자를 위한 실전 가이드입니다. 핵심 개념부터 자주 쓰는 명령어, 실수했을 때의 복구법까지 차례대로 정리했습니다. 이미 명령어를 외우는 중이라면 필요한 장만 꺼내 봐도 좋습니다.
먼저 알아야 할 세 가지 공간
Git은 파일을 세 공간에서 관리합니다. 이 구조를 이해하면 이후 명령어들이 훨씬 명확해집니다.
- 작업 디렉토리 (Working Directory): 실제로 내가 편집하고 있는 파일들.
- 스테이징 영역 (Staging Area, Index): "다음 커밋에 포함할" 변경 내역을 쌓아두는 임시 공간.
- 저장소 (Repository): 커밋이 확정되어 영구 기록으로 들어간 곳.
.git폴더 안에 있습니다.
"파일 수정 → git add로 스테이징 → git commit으로 저장소에 기록"의 흐름이 Git의 기본 사이클입니다.
최초 설정
Git을 처음 설치했다면 이름과 이메일을 한 번만 설정합니다. 모든 커밋에 표시됩니다.
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
기본 브랜치 이름을 main으로 두는 것이 요즘 표준입니다.
저장소 만들기와 가져오기
1. git init
현재 디렉토리를 Git 저장소로 만듭니다. 새 프로젝트를 시작할 때.
cd my-project
git init
2. git clone <url>
원격 저장소(GitHub 등)를 내려받습니다.
git clone https://github.com/user/repo.git
매일 쓰는 기본 사이클
3. git status
현재 무엇이 변경됐고, 무엇이 스테이징되어 있는지 보여줍니다. 가장 자주 쓰는 명령어이니 명령어 앞뒤로 습관처럼 치세요.
4. git add <파일>
파일의 변경 내역을 스테이징에 올립니다.
git add README.md # 특정 파일만
git add src/ # 디렉토리 전체
git add . # 현재 위치 아래 모든 변경
민감한 파일(.env, 키 파일)이 섞여 있을 수 있으니 git add . 전에는 반드시 git status로 확인하는 습관을 들이세요.
5. git commit -m "메시지"
스테이징된 변경을 커밋합니다. 메시지는 "무엇을 바꿨는가"보다 "왜 바꿨는가"를 짧게 쓰는 것이 좋습니다.
git commit -m "fix: 로그인 실패 시 에러 메시지 노출"
-m 없이 git commit만 치면 에디터가 열려 여러 줄 메시지를 쓸 수 있습니다.
6. git log
커밋 히스토리를 봅니다.
git log # 전체 로그
git log --oneline # 한 줄씩 간단히
git log --graph --oneline # 브랜치 그래프까지
7. git diff
변경 내용을 비교합니다.
git diff # 작업 디렉토리 vs 스테이징
git diff --staged # 스테이징 vs 마지막 커밋
git diff HEAD # 작업 디렉토리 vs 마지막 커밋
원격 저장소와 주고받기
8. git remote -v
연결된 원격 저장소 목록을 봅니다. origin이 관례적 이름.
9. git push
로컬 커밋을 원격으로 올립니다.
git push origin main
git push -u origin feature/login # 첫 push 시 -u로 추적 설정
10. git pull
원격의 새 커밋을 가져와 현재 브랜치에 병합합니다. 사실상 git fetch + git merge.
11. git fetch
원격의 변경을 내려받기만 하고 병합하지는 않습니다. 현재 작업에 영향을 주지 않고 확인만 하고 싶을 때.
브랜치 다루기
12. git branch
브랜치 목록을 봅니다. 현재 브랜치에는 *가 붙어 있습니다.
git branch # 로컬 브랜치 목록
git branch -a # 원격 포함
git branch feature/signup # 새 브랜치 생성 (이동은 X)
13. git switch <브랜치> / git checkout <브랜치>
브랜치를 전환합니다. switch가 새 명령어이며 checkout도 여전히 쓸 수 있습니다.
git switch main # main으로 이동
git switch -c feature/login # 새로 만들고 바로 이동 (= git checkout -b)
14. git merge <브랜치>
다른 브랜치의 변경을 현재 브랜치로 합칩니다.
git switch main
git merge feature/login
충돌이 발생하면 해당 파일을 열어 <<<<<<<, =======, >>>>>>> 표시를 보고 손으로 해결한 뒤 git add → git commit.
15. git branch -d <브랜치>
병합이 끝난 브랜치를 삭제. 강제 삭제는 -D.
실수 복구하기
16. git restore <파일>
작업 디렉토리의 변경을 마지막 커밋 상태로 되돌립니다. 저장되지 않은 수정이 사라지니 신중히.
git restore src/app.js # 파일 변경 폐기
git restore --staged app.js # 스테이징만 풀기
17. git reset
커밋 포인터를 옮기는 명령어. 용도별로 세 가지가 있습니다.
git reset --soft HEAD~1: 마지막 커밋 취소하고 변경 내용은 스테이징에 그대로 둠.git reset --mixed HEAD~1(기본): 커밋 취소하고 변경 내용은 작업 디렉토리에 둠.git reset --hard HEAD~1: 커밋·변경 내용 모두 삭제. 복구 어려움.
--hard는 되돌리기 어려운 작업이므로 원격에 아직 push하지 않은 커밋에만 신중히 쓰세요.
18. git revert <커밋>
이미 push한 커밋을 되돌릴 때의 정석. 해당 커밋을 상쇄하는 새 커밋을 만들어 히스토리를 보존합니다.
git revert 3a2b1c4
19. git stash
작업 중인 변경을 임시로 치워두고 싶을 때. 다른 브랜치로 잠깐 옮겨야 하는데 커밋하기엔 애매한 상태.
git stash # 변경사항 저장
git stash pop # 최근 stash 복원
git stash list # 저장된 stash 목록
20. git reflog
"뭐가 뭐였더라…" 싶을 때 구명줄. 최근 HEAD 이동 기록을 전부 보여주므로 --hard 리셋 후에도 커밋 해시만 알면 복구할 수 있습니다.
git reflog
git reset --hard HEAD@{2}
.gitignore — 추가로 알아둘 것
추적하고 싶지 않은 파일(빌드 결과, .env, OS 임시 파일)은 .gitignore에 적습니다.
node_modules/
dist/
.env
.DS_Store
*.log
프로젝트 시작과 동시에 세팅해야 합니다. 한 번 커밋된 파일은 .gitignore에 추가해도 계속 추적되므로 git rm --cached <파일>로 빼주세요.
안전하게 쓰기 위한 3가지 습관
- push 전에
git log·git diff로 반드시 확인. 공용 브랜치에 올라간 실수는 되돌리기 번거롭습니다. --forcepush는 신중히. 내 feature 브랜치 정도에만 쓰고,main/master에는 절대 금지.- 커밋은 작게, 자주. 한 커밋 = 한 주제가 원칙. 거대한 "중간 저장" 커밋을 만들면 나중에 해석이 어렵습니다.
막히면 이렇게 찾아보세요
Git 명령어에는 대부분 --help가 잘 되어 있습니다.
git help commit
git commit --help
그리고 명령어를 잊었더라도 git status는 늘 "다음에 뭘 하면 되는지"를 친절히 알려줍니다. 막히면 먼저 git status부터.
이 20개 명령어만 익숙해져도 일상적인 작업 대부분이 해결됩니다. Rebase, cherry-pick, bisect 같은 심화 주제는 여기에 익숙해진 뒤 차례대로 추가하세요.