GitHub와 Git을 11편으로 나눠 다룹니다 (원본 절 번호를 그대로 유지합니다).
- 1편 — Git과 GitHub의 차이, 3가지 영역, 설치와 상태 확인
- 2편 — 커밋 만들기, 좋은 커밋 메시지, 히스토리 조회와 .gitignore
- 3편 — 원격 저장소 인증(SSH·PAT)과 push·fetch·pull의 차이
- 4편 — 브랜치의 실체와 merge·rebase·충돌 해결
- 5편 — Pull Request, 머지 전략, force push, 브랜치 전략
- 6편 — reset·revert·reflog로 되돌리는 안전한 복구의 기술
- 7편 — rebase -i, cherry-pick, bisect와 히스토리를 다루는 도구들
- 8편 — GitHub Actions와 브랜치 보호 규칙
- 9편 — Pages·Releases·보안 기능·gh CLI와 오픈소스 기여
- 10편 — 실전 사고 복구 시나리오 12가지
- 11편 — 치트시트와 학습 로드맵
이 시리즈는 "명령어 암기"가 아니라 왜 그렇게 동작하는가를 이해하는 데 초점을 맞춥니다. 각 명령을 소개할 때마다 그 명령이 읽기 전용(안전)인지, 로컬만 바꾸는지, 원격 히스토리까지 바꾸는지(위험) 를 함께 표시합니다.
0.1 개념 정리
| Git | GitHub | |
|---|---|---|
| 정체 | 분산 버전 관리 시스템(프로그램) | Git 저장소를 호스팅하는 웹 서비스 |
| 위치 | 내 PC에 설치됨 | 클라우드 (github.com) |
| 오프라인 | 대부분 기능 동작 | 네트워크 필요 |
| 만든 곳 | 리누스 토르발스 (2005) | GitHub Inc. (2008, 현재 Microsoft) |
| 대체재 | Mercurial, SVN(중앙집중식) | GitLab, Bitbucket, Gitea |
핵심은 이것입니다. Git을 몰라도 GitHub는 못 쓰고, GitHub를 몰라도 Git은 쓸 수 있습니다. 그래서 이 시리즈는 Git부터 시작합니다.
0.2 "분산"이 의미하는 것
SVN 같은 중앙집중식은 서버에만 전체 히스토리가 있습니다. 서버가 죽으면 끝입니다.
Git은 clone을 하는 순간 전체 히스토리의 완전한 복사본이 내 PC에 생깁니다.
[GitHub 원격 저장소] ← 완전한 히스토리
↕ push / fetch
[내 PC 로컬 저장소] ← 완전한 히스토리 (똑같음)이 구조 때문에 생기는 중요한 결과:
- 커밋, 브랜치 생성, 히스토리 조회는 전부 오프라인에서 동작합니다. (빠른 이유)
- 로컬에서 무슨 짓을 해도
push하기 전까지 원격은 절대 안 바뀝니다. - 반대로 한번
push한 것을 되돌리는 건 훨씬 조심스러운 일이 됩니다.
안전 원칙 #1 — 로컬 작업과 원격 작업을 머릿속에서 분리하세요. "이 명령이 원격을 건드리는가?"가 위험도를 가르는 1차 기준입니다. 원격을 바꾸는 것은 사실상
push계열(push,push --force,push --delete,push --tags)과gh같은 별도 도구뿐입니다.fetch·clone·log는 원격에서 읽기만 합니다.
0.3 Git의 3가지 영역 (가장 중요한 그림)
작업 디렉토리 스테이징 영역 로컬 저장소 원격 저장소
(Working Directory) (Staging/Index) (.git/objects) (GitHub)
│ │ │ │
│──── git add ─────────▶│ │ │
│ │──── git commit ──────▶│ │
│ │ │──── git push ─────▶│
│◀─── git restore ──────│ │ │
│ │◀── git restore --staged │
│◀──────────── git checkout / switch ───────────│ │
│ │ │◀─── git fetch ─────│스테이징 영역(Index)이 왜 있는가? 이게 Git 입문의 첫 번째 관문입니다.
작업하다 보면 파일 5개를 고쳤는데 그중 3개는 "로그인 버그 수정", 2개는 "오타 수정"인 경우가 생깁니다. 스테이징 영역이 있으면 3개만 골라 커밋하고, 나머지 2개를 별도 커밋으로 나눌 수 있습니다. 커밋을 의미 단위로 쪼갤 수 있게 해주는 완충 지대입니다.
모델을 잡았으니 이제 실제로 설치하고 저장소를 만들어 봅니다.
1.1 설치와 최초 설정
# 설치 확인
git --version # 2.28 이상 권장 (switch/restore는 2.23+, init.defaultBranch는 2.28+)
# 필수 설정 — 커밋에 기록될 신원
git config --global user.name "Hong Gildong"
git config --global user.email "hong@example.com"
# 기본 브랜치 이름을 main으로 (Git 2.28+)
git config --global init.defaultBranch main
# 줄바꿈 처리 (중요!)
git config --global core.autocrlf true # Windows
git config --global core.autocrlf input # macOS / Linux
# 한글 파일명 깨짐 방지
git config --global core.quotepath false
# 설정 전체 확인 (읽기 전용, 안전)
git config --list --show-originGit 본체의 기본 브랜치 이름은 2026년 9월 현재도 master이고, Git 3.0에서 main으로 바뀔 예정입니다. GitHub가 2020년 10월부터 새 저장소를 main으로 만들면서 main이 사실상의 관례가 됐으므로, 위 설정으로 로컬도 맞춰두는 편이 낫습니다. 이 설정은 Git 2.28 이상에서만 동작하고, 그 아래 버전에서는 오류 없이 조용히 무시됩니다.
core.autocrlf를 설명하는 이유: Windows는 줄바꿈이 CRLF, Unix 계열은 LF입니다. 설정하지 않으면 코드 한 줄도 안 고쳤는데 파일 전체가 변경된 것으로 잡히는 일이 생깁니다. 팀 프로젝트에서 diff가 지저분해지는 가장 흔한 원인입니다.
더 확실한 해결책은 저장소 루트에 .gitattributes를 두는 것입니다.
* text=auto eol=lf
*.bat text eol=crlf
*.sh text eol=lf
*.png binary
*.jpg binary.gitattributes는 저장소에 커밋되므로 팀 전원에게 동일하게 적용됩니다. core.autocrlf는 개인 설정이라 사람마다 달라질 수 있습니다. 팀이라면 .gitattributes를 쓰세요.
1.2 저장소 만들기
# 새로 시작
mkdir my-project && cd my-project
git init # .git 폴더 생성 (여기에 모든 히스토리가 들어감)
# 기존 원격 저장소 가져오기
git clone https://github.com/user/repo.git
git clone https://github.com/user/repo.git my-folder # 폴더명 지정.git 폴더를 지우면 히스토리가 전부 날아갑니다. 반대로 .git만 있으면 어디서든 복원됩니다.
1.3 상태 확인 — 모든 작업의 시작점
git status # 현재 상태 (읽기 전용, 안전)
git status -s # 짧게 (-s = short)
git diff # 작업 디렉토리 vs 스테이징
git diff --staged # 스테이징 vs 마지막 커밋
git diff HEAD # 작업 디렉토리 vs 마지막 커밋 (전체)git status -s의 두 글자 기호를 읽는 법:
M file.txt # 수정됨, 스테이징 안 됨 (왼쪽=스테이징, 오른쪽=작업디렉토리)
M file.txt # 수정됨, 스테이징 됨
MM file.txt # 스테이징 후 또 수정함
A file.txt # 새 파일, 스테이징 됨
?? file.txt # Git이 추적하지 않는 파일
D file.txt # 삭제됨안전 원칙 #2 — 무언가 하기 전에
git status, 뭔가 잘못됐다 싶으면git status.status,diff,log,show,fetch는 전부 읽기 전용입니다. 아무리 많이 실행해도 안전합니다. 혼란스러울 때 상황을 파악하는 비용은 0입니다.