이전 편: 10편 — 실전 사고 복구 시나리오 12가지
8.1 일상 워크플로 요약
# 하루 시작
git switch main
git fetch origin
git log --oneline HEAD..origin/main # 뭐가 바뀌었나 확인
git merge origin/main
# 작업 시작
git switch -c feature/task-name
# 작업 중
git status
git add -p
git commit -m "feat: 설명"
# 공유
git push -u origin feature/task-name
gh pr create
# 마무리
git switch main
git fetch origin --prune
git merge origin/main
git branch -d feature/task-name8.2 명령어 요약표
조회 (전부 안전)
git status 현재 상태
git log --oneline --graph 히스토리 그래프
git diff 변경 내용
git show <commit> 커밋 상세
git blame <file> 줄별 작성자
git reflog HEAD 이동 기록 (복구용)
git branch -a 브랜치 목록
git remote -v 원격 목록
git fetch 원격 정보 갱신변경
git add -p 선택적 스테이징
git commit -m "" 커밋
git commit --amend 마지막 커밋 수정
git switch -c <br> 브랜치 생성+이동
git merge <br> 병합
git rebase <br> 재배치
git cherry-pick <c> 커밋 선택 적용
git stash / apply 임시 저장되돌리기 명령의 차이는 6편에 정리돼 있습니다.
되돌리기
git restore <file> 작업 변경 취소 ⚠
git restore --staged <f> 스테이징 해제
git reset --soft HEAD~1 커밋만 취소
git reset --hard HEAD~1 전부 취소 ⚠
git revert <commit> 취소 커밋 생성 ✅
git merge --abort 병합 중단
git rebase --abort 리베이스 중단원격 명령의 위험도 분류는 3편에 있습니다.
원격
git push -u origin <br> 푸시 + 추적
git push --force-with-lease --force-if-includes 강제 푸시(동료 커밋 보호)
git push origin --delete <br> 원격 브랜치 삭제 ⚠
git fetch --all --prune 전체 갱신 + 정리8.3 안전 원칙 5가지 (최종 정리)
- 로컬과 원격을 분리해서 생각한다. 커밋한 것이라면 push 전에는 거의 무엇을 해도 reflog로 되돌릴 수 있다.
- 행동 전에
status, 의심되면log. 읽기 전용 명령의 비용은 0이다. - 위험한 명령 전에는 백업 브랜치.
git branch backup/$(date +%m%d-%H%M) - 원격에 있는 것은 지우지 말고 덮어쓴다.
reset+force가 아니라revert. - 커밋 안 된 변경은 Git의 보호 밖이다. 일단 커밋하거나 stash하라.
8.4 추천 글로벌 설정
# 기본
git config --global init.defaultBranch main
git config --global pull.rebase false # pull을 쓸 때의 동작을 merge로 못박음(권장 흐름은 3편의 fetch → 검토 → merge)
git config --global fetch.prune true # fetch 시 사라진 브랜치 자동 정리
# push.default는 기본값이 simple이며 Git 문서가 입문자에게 가장 안전한 값으로 권합니다.
# 아래 current는 -u 없이 바로 push하는 편의를 위한 것으로, 원격에 같은 이름 브랜치를 새로 만들 수 있다는 점을 알고 쓰세요.
git config --global push.default current # 같은 이름 브랜치로 push
git config --global rerere.enabled true # 충돌 해결 기억
# 편의 alias
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.sw switch
git config --global alias.last "log -1 HEAD --stat"
git config --global alias.unstage "restore --staged"
git config --global alias.pushf "push --force-with-lease --force-if-includes"
git config --global alias.lg "log --graph --pretty=format:'%C(yellow)%h%Creset -%C(auto)%d%Creset %s %C(dim)(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"pull.rebase false는 pull을 쓰라는 권유가 아니라, 쓰게 될 때 merge로 동작하도록 못박는 설정입니다. 권장 흐름은 3편의 fetch → 검토 → merge 그대로입니다.
8.5 학습 로드맵
1주차 — 기초 체득
init add commit status log / .gitignore / GitHub 계정 + SSH 키 / 개인 저장소 하나 만들어 매일 커밋
2주차 — 브랜치
branch switch merge / 충돌 일부러 만들어보고 해결 / PR 만들어보기 / --oneline --graph로 결과 눈으로 확인
3주차 — 되돌리기
reset 3모드 차이 / revert vs reset / reflog로 일부러 날린 커밋 복구해보기 / stash
→ 연습용 저장소를 만들어서 일부러 망가뜨리고 복구하는 것이 가장 빠른 학습법입니다.
4주차 — 심화
rebase -i로 커밋 정리 / cherry-pick / GitHub Actions로 CI 구성 / 브랜치 보호 규칙 설정
이후 — 실전
오픈소스에 PR 보내보기 (문서 오타부터) / 팀 브랜치 전략 설계 / bisect로 버그 추적 / worktree 도입
8.6 참고 자료
- Pro Git (한국어 무료) — 사실상 공식 교과서
- Learn Git Branching — 시각적 인터랙티브 학습
- Oh Shit, Git!?! — 상황별 복구 레시피
- GitHub Docs
- Conventional Commits
- Semantic Versioning
- gitignore 템플릿 모음
마치며
Git이 어렵게 느껴지는 이유는 명령어가 많아서가 아니라, "이 명령이 어디를 바꾸는가" 라는 모델이 없기 때문입니다.
- 작업 디렉토리 / 스테이징 / 로컬 저장소 / 원격 저장소 — 이 4단계 (1편)
- 브랜치는 커밋을 가리키는 포인터일 뿐이라는 사실 (4편)
- 커밋된 것은 reflog로 거의 항상 살아나고, 커밋 안 된 것은 못 살린다는 사실 (6편)
이 세 가지만 머릿속에 자리 잡으면 나머지 명령은 전부 "어느 화살표를 움직이는가"로 설명됩니다.
그리고 마지막으로, 숙련도는 얼마나 많은 명령을 아는가가 아니라 얼마나 적은 위험을 감수하는가로 측정됩니다. 잘 하는 사람일수록 --force를 덜 쓰고, status를 더 자주 치고, 백업 브랜치를 더 많이 만듭니다.
더 깊이
- 4주차 로드맵의 "GitHub Actions로 CI 구성" 다음 단계는 풀스택 개발자를 위한 CI/CD 1강 — CI/CD란 무엇인가입니다.