Git 초보 탈출 — 실무에서 쓰는 명령어 정리

이 글에서 다루는 내용

git add . && git commit && git push만 쓰는 단계를 벗어나 실제 팀 협업에서 마주치는 상황(브랜치 관리, 충돌 해결, 되돌리기, 커밋 정리)을 Git 명령어 중심으로 정리합니다. 혼자 쓰는 Git에서 팀 Git으로 넘어갈 때 필요한 기본기만 압축했습니다.

Git이 어려운 이유의 절반은 명령어가 많아서가 아니라 상태 모델이 머리에 안 들어와서입니다. 작업 트리(Working Directory) / 스테이지(Staging) / 로컬 저장소 / 원격 저장소의 4단 구조만 명확해지면, 이후 모든 명령은 "이 영역에서 저 영역으로 무엇을 옮긴다"는 단순한 그림으로 정리됩니다. 이 글의 모든 예시도 그 그림 위에서 이해해 보시면 훨씬 빨라집니다.

Git 4단 상태 모델 Working 파일 수정 에디터로 작업 add Staging 커밋 후보 git diff --cached commit Local Repo 로컬 히스토리 .git/objects push Remote GitHub·GitLab 팀 공유 반대 방향(pull·fetch·restore·reset)도 같은 그림 위에서 이해할 수 있습니다.

---

1. 환경 초기 설정

1-1. 이름과 이메일

커밋에 박히는 정보입니다. 팀 표준에 맞춰 정확히 적습니다. 회사 깃 서버는 이메일 도메인 검증을 하는 경우가 많으니, 사내 이메일과 일치시키는 편이 안전합니다.

git config --global user.name "Sehyun Cho"
git config --global user.email "you@example.com"

1-2. 기본 브랜치, 에디터, Pull 방식

git config --global init.defaultBranch main
git config --global core.editor "code --wait"
git config --global pull.rebase false

설정	설명
init.defaultBranch	새 저장소 생성 시 기본 브랜치 이름
core.editor	커밋 메시지 작성기
pull.rebase	git pull 시 rebase 여부. 팀 정책에 맞춤

1-3. .gitignore 기본 설정

처음부터 .gitignore를 잘 잡아두면 이후 실수로 비밀번호·캐시·빌드 산출물을 커밋하는 사고를 막을 수 있습니다. 자주 들어가는 항목은 다음과 같습니다.

.venv/
__pycache__/
node_modules/
.env
.DS_Store
*.log

각 언어별 추천 템플릿은 github/gitignore 저장소에서 그대로 가져올 수 있습니다.

---

2. 일상 워크플로

2-1. 기본 순환

git status
git diff
git add <file>
git commit -m "feat: 로그인 API 추가"
git push origin feature/login

2-2. 커밋 메시지 컨벤션

Conventional Commits 기준을 권장합니다. 메시지 앞에 종류 접두사를 붙이는 것만으로도 자동 릴리스 노트·CHANGELOG 생성 도구를 그대로 활용할 수 있어 장기 가치가 큽니다.

접두사	의미
feat	기능 추가
fix	버그 수정
docs	문서
refactor	리팩터링
test	테스트 코드
chore	빌드/설정

💡 커밋 메시지는 "무엇을 했는가"가 아니라 "왜 했는가"를 남기는 것이 가치 있습니다. 제목 50자, 본문은 자유롭게.

2-3. 변경을 작게 쪼개 커밋

git add -p를 쓰면 같은 파일 안의 변경을 부분(hunk) 단위로 골라 스테이지에 올릴 수 있습니다. 큰 변경을 한 번에 묶지 말고 의미 단위로 잘게 자르면 PR 리뷰가 훨씬 수월해집니다.

git add -p
# y/n/s 등으로 hunk를 골라 스테이지에 추가

---

3. 브랜치 관리

3-1. 기본 명령

git branch                      # 로컬 브랜치 목록
git branch -a                   # 원격 포함
git switch -c feature/login     # 새 브랜치 생성 + 이동
git switch main                 # 기존 브랜치 이동
git branch -d feature/login     # 병합된 브랜치 삭제
git branch -D feature/login     # 강제 삭제

3-2. 원격 브랜치 동기화

git fetch --prune               # 원격 최신 + 삭제된 브랜치 정리
git pull --ff-only              # fast-forward만 허용

--ff-only는 의도치 않은 merge 커밋 생성을 방지합니다. --prune은 이미 삭제된 원격 브랜치의 추적 정보를 정리해 로컬 브랜치 목록을 깔끔하게 유지해 줍니다.

---

4. 병합과 리베이스

4-1. merge

git switch main
git merge feature/login

히스토리에 merge 커밋이 남습니다. 팀 리뷰 흐름에는 이 방식이 직관적이고, 어떤 PR이 언제 합쳐졌는지 한눈에 보입니다.

4-2. rebase

git switch feature/login
git rebase main

히스토리가 "한 줄"로 깔끔해지지만, 공유된 브랜치에서는 강제 푸시가 필요해 주의가 필요합니다.

⚠️ 원격에 이미 올라간 브랜치를 rebase하면 다른 사람의 로컬과 어긋납니다. 내 작업 브랜치에 한정해서 사용하세요.

4-3. 어느 쪽을 언제 쓰는가

실무에서는 두 전략을 동시에 쓰는 경우가 많습니다. 작업 브랜치 안에서는 rebase로 커밋을 깔끔하게 정리하고, main으로 합칠 때는 merge로 PR 단위의 히스토리를 유지하는 식입니다. 팀이 어떤 정책을 쓰는지 처음에 한 번만 합의해두면 이후 혼란이 거의 사라집니다.

팀 단위 합의가 어려울 때는 GitHub의 "Squash and merge", "Rebase and merge" 같은 기본 옵션 중 하나로 통일하는 것도 방법입니다. 어떤 옵션이든 일관되게만 적용되면, 시간이 지나도 히스토리가 읽기 쉬운 상태로 유지됩니다.

---

5. 되돌리기

5-1. 스테이지 취소

git restore --staged <file>

5-2. 작업 변경 폐기

git restore <file>

5-3. 마지막 커밋 수정

git commit --amend

5-4. 특정 커밋을 반대로 적용

git revert <commit>

revert는 새 커밋을 만들어 되돌리므로 히스토리를 안전하게 보존합니다. 공유 저장소에서 가장 선호되는 방식입니다.

5-5. 리셋(로컬 전용)

git reset --soft HEAD~1      # 커밋만 취소, 변경은 보존
git reset --hard HEAD~1      # 변경까지 버림 (주의)

---

6. 실전에서 자주 쓰는 도구

6-1. stash

작업 중간에 급하게 브랜치 이동이 필요할 때.

git stash push -m "로그인 작업 중"
git switch hotfix/payment
# 핫픽스 처리 후
git switch feature/login
git stash pop

6-2. cherry-pick

다른 브랜치의 특정 커밋만 가져올 때. 핫픽스를 main과 release 두 브랜치에 모두 반영하는 시나리오에서 유용합니다.

git cherry-pick <commit>

6-3. log 시각화

git log --oneline --graph --decorate --all

예시 출력

* a1b2c3d (HEAD -> feature/login) feat: 소셜 로그인
* d4e5f6a feat: 이메일 로그인
| * 9g8h7i6 (main) fix: 타임존 버그
|/
* 1234567 init

6-4. bisect로 회귀 버그 추적

어디서부터 버그가 생겼는지 모를 때 git bisect가 빠릅니다. 정상이었던 옛 커밋과 현재 사이를 이진 탐색해 원인 커밋을 찾아줍니다.

git bisect start
git bisect bad                 # 현재가 버그
git bisect good v1.0.0         # 정상이었던 시점
# 자동으로 중간 커밋을 체크아웃 → 테스트 후 good/bad 입력
git bisect reset               # 끝나면 정리

---

트러블슈팅

문제 1: 푸시가 rejected

원격에 내가 모르는 커밋이 있습니다.

git pull --rebase
# 충돌 해결
git rebase --continue
git push

문제 2: 병합 충돌

파일을 열면 <<<<<<<, =======, >>>>>>> 마커가 보입니다. 원하는 내용만 남기고 마커는 삭제한 뒤 저장, 이후 아래를 실행합니다.

git add <file>
git commit          # merge 진행 중이면 자동으로 메시지 작성

문제 3: 커밋 작성자(이메일)가 잘못 들어감

최근 커밋이라면 amend로 고칠 수 있습니다.

git commit --amend --author="Sehyun Cho <you@example.com>"

문제 4: 실수로 reset --hard

잃어버린 커밋은 보통 reflog에 남아 있습니다.

git reflog
git reset --hard <해시>

---

마무리

Git은 "명령어 많은 도구"가 아니라 "상태 모델을 명령어로 드러내는 도구"입니다. 작업 트리 / 스테이지 / 로컬 저장소 / 원격 저장소 4단 구조만 머릿속에 들어가면, 이 글의 모든 명령어가 자연스럽게 연결됩니다. 익숙해진 뒤에는 git worktree나 git submodule 같은 고급 기능도 같은 모델 위에서 빠르게 이해됩니다. 이후 GitHub Actions 편에서는 이 Git 위에 CI를 얹는 흐름을 다룹니다.

실수했을 때 가장 든든한 안전망은 reflog입니다. 90일 이내의 모든 HEAD 이동 기록이 그대로 남아 있어, "어제까지 분명 있었는데" 상황의 대부분이 reflog 한 번이면 복구됩니다. 새 명령을 시도하기 전에 "지금 상태 reflog에 잘 찍혔는지" 정도만 가볍게 의식해 두면, 두려움 없이 다양한 명령을 시험해 볼 수 있게 됩니다. 이 안전망이 있다는 사실 자체가 Git을 학습할 때 가장 큰 자산입니다. 그래서 명령어를 외우기보다 "이 명령이 어느 영역에 어떤 변화를 만드는가"를 그려 보면서 익히는 편이 훨씬 빠르고 오래 갑니다.

• 공식 문서: https://git-scm.com/doc
• 관련 글: VS Code 개발 환경 최적화 세팅

함께 읽으면 좋은 글

• Python 가상환경(venv) 완벽 정리
• Python 가상환경 Anaconda 완벽 정리