Git 실전 가이드 시리즈 목차 | 기초·브랜치·원격·rebase

작성 0xmote · 2026년 2월 24일 · 12분 읽기 · 수정 2026년 9월 24일 초급 개념

이 글의 핵심

분산 버전 관리 Git의 목적과 함께, 기초→브랜치·병합→원격·되돌리기·rebase 순서의 실무 목차와 용어·명령 요약을 한 페이지에 모았습니다.

Git 시리즈 목차

Git 설치·커밋부터 브랜치·병합·원격 협업·되돌리기까지 실무 순서로 정리한 시리즈의 목차입니다.

Git이 생긴 배경과 이 순서를 읽는 이유

Git은 2005년 리누스 토르발스가 리눅스 커널 개발을 위해 만든 분산 버전 관리 시스템입니다. 중앙 서버 하나에만 히스토리가 있던 도구와 달리, 각 개발자의 로컬에 전체 히스토리(또는 그에 가까운 복사본)를 두는 설계 덕분에 오프라인 커밋, 브랜치 실험, 원격과의 비동기 협업이 자연스럽습니다. 대신 처음에는 “스테이징이 왜 두 단계인지”, “merge와 rebase 중 뭘 쓰는지”처럼 개념이 한 번에 들어오지 않을 수 있습니다.

이 목차는 로컬에서 안전하게 익힐 것(#1~#2) → 다른 사람·원격과 맞출 것(#3) → 잘못 올린 것·히스토리를 정리할 것(#4) 순으로 배치했습니다. 혼자 쓸 때는 #1~#2만으로도 충분하지만, 팀과 PR을 쓰기 시작하면 #3이, “이미 push한 커밋을 고치고 싶다”는 순간에 #4가 필요해집니다.

읽는 순서: #1 기초 입문 → #2 브랜치와 병합 → #3 원격·협업 → #4 되돌리기·rebase. 이미 커밋·푸시에 익숙하시다면 필요한 편만 골라 읽으셔도 됩니다.

Git이 하는 일을 한 문장으로

Git은 프로젝트 폴더의 스냅샷(커밋)을 시간 순으로 쌓아 두는 도구입니다. 로컬에는 작업 폴더(Working Tree) · 스테이징(Index) · 로컬 저장소(.git) 가 있으며, 원격(GitHub 등)과 push / pull로 동기화합니다. 각 편은 이 흐름 안에서 자주 막히는 지점(충돌, 되돌리기, rebase)을 풀어 줍니다.

처음 배울 때 가장 헷갈리는 것이 “왜 저장(커밋) 전에 add라는 단계가 하나 더 있나”인데, 스테이징이 있기 때문에 한 파일 안의 변경 중 일부만 골라 커밋할 수 있습니다. 버그 수정과 리팩터링을 동시에 해 버렸을 때 git add -p로 버그 수정 부분만 먼저 커밋하면, 나중에 문제가 생겼을 때 어느 변경이 원인인지 커밋 단위로 추적하고 되돌리기 쉬워집니다. 또 Git은 파일의 차이가 아니라 스냅샷을 저장하고, 커밋 해시는 내용과 부모 커밋에서 계산됩니다. 그래서 이미 공유한 커밋을 수정(amend, rebase)하면 해시가 바뀌어 “다른 커밋”이 되고, #4편에서 다루는 force push 문제가 여기서 생깁니다.

핵심 용어 (시리즈를 읽을 때 같이 보면 좋음)

용어	의미
커밋	특정 시점의 파일 상태를 저장한 기록(해시로 식별).
브랜치	커밋 줄기의 이름. `main`과 `feature`처럼 나눠 개발할 때 사용.
HEAD	지금 체크아웃된 커밋(또는 브랜치)을 가리키는 포인터.
원격(remote)	`origin` 등, 서버에 있는 저장소 별칭.
스테이징	`git add`로 “다음 커밋에 넣을 변경”을 고르는 단계.
원격 추적 브랜치	`origin/main`처럼 마지막 fetch 시점의 원격 상태를 로컬에 기록한 읽기 전용 브랜치.

HEAD가 브랜치가 아니라 특정 커밋을 직접 가리키는 상태를 detached HEAD라고 부릅니다. git checkout <커밋해시>나 태그를 체크아웃하면 이 상태가 되는데, 여기서 커밋을 만들고 다른 브랜치로 옮겨 가면 그 커밋은 어떤 브랜치에도 속하지 않아 “사라진 것처럼” 보입니다. 실제로는 git reflog에 남아 있으므로 해시를 찾아 git branch 새이름 <해시>로 살릴 수 있습니다. 작업을 이어 갈 생각이라면 처음부터 git switch -c 새브랜치로 브랜치를 만들어 두는 것이 안전합니다.

자주 쓰는 명령 (주석으로 흐름 정리)

아래는 이 시리즈를 읽기 전/후에 손에 익혀 두면 좋은 최소 세트입니다. 각 줄 옆 주석은 “무슨 단계인지”만 짚습니다.

# 현재 변경 상태 확인 (작업 트리 vs 스테이징)
git status
# 수정 파일을 다음 커밋 후보로 올림 (스테이징)
git add 파일명
# 또는 전부
git add -A
# 스테이징된 내용으로 커밋 (로컬 히스토리에 스냅샷 1개 추가)
git commit -m "설명 메시지"
# 원격 브랜치와 동기화 (받아오기)
git pull origin 브랜치이름
# 로컬 커밋을 원격에 올리기
git push origin 브랜치이름
# 브랜치 목록 / 전환
git branch
git checkout 브랜치이름   # 또는: git switch 브랜치이름

git pull = 보통 원격에서 가져온 뒤 현재 브랜치에 합치는 과정(fetch + merge/rebase)을 통칭합니다. 팀 규칙에 따라 rebase를 쓰는 경우가 많습니다(4편 참고).

위 명령 세트에서 초보자가 실제로 사고를 내는 곳은 두 군데입니다. 첫째는 git add -A입니다. 작업 폴더의 모든 변경과 새 파일을 올리기 때문에, .gitignore에 등록하지 않은 .env, API 키가 든 설정 파일, 빌드 결과물, 수백 MB짜리 데이터 파일이 한꺼번에 커밋됩니다. 저도 초기에 .env를 이렇게 커밋해 원격에 올린 적이 있는데, 다음 커밋에서 파일을 지워도 히스토리에는 그대로 남아 누구나 예전 커밋에서 꺼내 볼 수 있다는 사실을 그때 배웠습니다. 이미 푸시한 비밀 값은 히스토리 정리(git filter-repo 등)보다 키를 먼저 폐기·재발급하는 것이 올바른 순서입니다. 그래서 git add -A 전에는 git status로 목록을 확인하고, 가능하면 파일명을 지정해 올리는 습관이 좋습니다.

둘째는 git pull의 기본 동작입니다. 로컬과 원격에 서로 다른 커밋이 있는 상태(갈라진 브랜치)에서 pull하면, 설정에 따라 merge 커밋이 자동으로 생기거나 Git 2.27 이후에는 hint: You have divergent branches and need to specify how to reconcile them. 메시지와 함께 멈춥니다. 이때 git config --global pull.rebase false(merge), true(rebase), 또는 pull.ff only(빨리 감기만 허용) 중 하나를 팀 규칙에 맞게 정해 두면 됩니다. 명령어 표에 함께 적힌 git switch는 Git 2.23에서 checkout의 “브랜치 전환” 역할만 떼어 낸 명령이라, 파일을 되돌리는 checkout -- 파일(현재는 git restore)과 헷갈릴 일이 줄어듭니다.

이 목차 다음에 읽을 만한 글

C++ 위주 블로그라면 C++ 실전 가이드 목차와 병행해 두면, 문서·코드 저장소를 같은 Git 흐름으로 관리하기 쉽습니다.

#1 — 기초

#1 Git 기초 입문 — 설치·커밋·스테이징·원격 기본

#2 — 브랜치·병합

#2 Git 브랜치와 병합 — branch, checkout, merge, 충돌 해결

#3 — 원격·협업

#3 Git 원격 저장소와 협업 — push, pull, fetch, PR

#4 — 되돌리기·정리

#4 Git 되돌리기·rebase·정리 — reset, revert, rebase

같이 보면 좋은 글

실무에서 Git을 쓸 때의 팁

git status를 습관화합니다. “지금 스테이징에 뭐가 올라가 있지?”를 모른 채 커밋하면, 의도하지 않은 파일이 포함되기 쉽습니다.
커밋 메시지는 나중의 나를 위한 메모입니다. “수정”보다는 “무엇을·왜”를 한 줄이라도 적어 두면, git log로 장애 원인 추적이 쉬워집니다.
pull 전에 로컬 작업을 정리합니다. 큰 변경을 들고 있을 때는 stash나 임시 브랜치를 쓰는 팀 규칙을 정해 두면 충돌이 줄어듭니다.
force push는 팀 규칙과 함께입니다. 공유 브랜치에서 히스토리를 다시 쓰면 동료의 로컬과 어긋날 수 있어, #4편의 rebase·reset 설명과 함께 읽는 것이 안전합니다. 꼭 필요하다면 git push --force 대신 --force-with-lease를 쓰세요. 내가 마지막으로 본 원격 상태 이후에 누군가 푸시했다면 거부해 주므로, 동료의 커밋을 모르고 덮어쓰는 사고를 막아 줍니다.
실수했을 때는 git reflog부터 봅니다. reset으로 커밋을 날렸거나 rebase가 꼬였어도, 로컬에서 HEAD가 거쳐 간 위치는 reflog에 기본 90일 정도 남아 있어 대부분 되살릴 수 있습니다. 당황해서 저장소를 지우고 다시 clone하면 푸시하지 않은 작업이 정말로 사라집니다.

자주 묻는 질문 (FAQ)

Q. `git pull`과 `git fetch`는 무엇이 다른가요?

A. git fetch는 원격의 새 커밋을 받아 origin/main 같은 원격 추적 브랜치만 갱신하고, 내 작업 브랜치는 건드리지 않습니다. git pull은 fetch 뒤에 현재 브랜치에 merge 또는 rebase까지 한 번에 수행합니다. 원격에서 무엇이 바뀌었는지 먼저 보고 합치고 싶다면 fetch로 받아 git log HEAD..origin/main으로 확인한 뒤 합치는 편이 안전합니다.

Q. merge와 rebase는 무엇을 먼저 익혀야 하나요?

A. merge로 분기와 합치기를 먼저 이해한 뒤, rebase는 히스토리를 일직선으로 정리하는 선택지로 배우는 흐름이 이해에 도움이 됩니다. #2에서 병합과 충돌, #4에서 rebase와 되돌리기를 다루므로 해당 편을 함께 참고하세요.