브랜치 & 병합 매뉴얼

한 줄기 코드를 여러 갈래로 나눠 따로 작업하고 다시 하나로 합치는 핵심 명령어 모음 | 공식 문서: git-scm.com/docs/git-branch

대상 Git 버전2.40 이상 (최신 안정판 2.54.0 기준)

참조 문서 URLgit-branch · git-switch · git-merge

문서 수집일2026년 6월 13일

버전 확인 방법git --version

대상 독자Git 기초를 익힌 입문자 (바이브코딩 수업)

명령어 트리 (Command Tree)

git
├── [브랜치 만들기·보기]
│   ├── git branch                 브랜치 목록 보기 (* 표시가 현재 위치)
│   ├── git branch <이름>          새 브랜치 생성 (이동은 안 함)
│   └── git branch -a              원격 포함 전체 브랜치 보기
│
├── [브랜치 이동]  (최신 권장)
│   ├── git switch <브랜치>        해당 브랜치로 이동
│   ├── git switch -c <새브랜치>   새 브랜치를 만들면서 바로 이동
│   └── git switch -              직전에 있던 브랜치로 되돌아가기
│
├── [합치기]
│   ├── git merge <브랜치>         다른 브랜치의 변경을 현재 브랜치로 병합
│   └── git merge --abort          충돌 등으로 병합을 중단하고 원상복구
│
├── [정리]
│   ├── git branch -d <이름>       병합 끝난 브랜치 삭제
│   └── git branch -m <새이름>     현재 브랜치 이름 바꾸기
│
└── [참고: 구식 명령]
    └── git checkout             예전엔 이동·복구를 다 했음 → 지금은 switch / restore 권장

💡 흐름 한 줄 요약: git switch -c feature/x로 갈라져 나가 작업 → git commit으로 저장 → git switch main으로 돌아와 git merge feature/x로 합치기. 이 갈라짐 → 합침 리듬이 브랜치 사용의 핵심입니다.

1. 브랜치란? (Branch)

💡 배경 개념: 브랜치가 뭔가요?

브랜치는 커밋들이 이어진 독립된 작업선입니다. 같은 코드에서 갈라져 나와, 본래 코드에 영향을 주지 않고 마음껏 실험하고 개발한 뒤, 작업이 끝나면 다시 합칩니다. 비유하자면 나뭇가지와 같습니다. 굵은 줄기(main)에서 가지를 뻗어 거기서 열매를 키워 보고, 잘 자랐으면 줄기에 그 성과를 합치고, 실패한 가지는 그냥 잘라내면 됩니다. 줄기 자체는 늘 안전합니다.

기본 브랜치 이름은 보통 main입니다. 새 기능을 만들 때마다 가지를 쳐서 따로 작업하면, 작업 중인 미완성 코드가 main을 망치지 않습니다. 여러 사람이 각자 다른 가지에서 동시에 일할 수도 있습니다.

HEAD — "지금 내가 어디에 있나"

브랜치를 이해하려면 HEAD라는 개념이 함께 필요합니다. HEAD는 현재 내가 있는 브랜치(또는 커밋)를 가리키는 포인터입니다. 브랜치를 이동하면 HEAD가 그 브랜치를 가리키도록 옮겨지고, 그에 맞춰 작업 폴더의 파일들도 그 브랜치의 내용으로 바뀝니다.

📌 브랜치는 '가벼운 책갈피'입니다. 코드를 통째로 복사하는 게 아니라, 특정 커밋을 가리키는 이름표 하나일 뿐입니다. 그래서 브랜치를 만드는 일은 순식간이고, 부담 없이 여러 개 만들었다 지울 수 있습니다.

브랜치를 쓰면 좋은 점

안전한 실험: 별도 가지에서 시도하므로 실패해도 main은 멀쩡합니다.
병행 작업: 기능 A와 기능 B를 각각 다른 브랜치에서 동시에 진행할 수 있습니다.
깔끔한 이력: 기능 단위로 가지를 나누면 "이 변경 묶음이 무슨 작업이었는지"가 분명해집니다.
협업: 각자 자기 브랜치에서 일하고 합치므로 서로의 작업을 덜 방해합니다.

입문자용 브랜치 전략

현업에서는 main을 항상 동작하는 상태로 두고, 기능마다 feature/이름 같은 브랜치를 따서 작업한 뒤 합치는 방식이 흔합니다(이른바 feature branch). 입문 단계에서는 복잡한 규칙 없이 "main + 기능 브랜치" 한 가지 패턴이면 충분합니다.

💡 Git과 GitHub의 브랜치는 같은 개념입니다. 브랜치 자체는 내 컴퓨터의 Git 기능이고, 그 브랜치를 GitHub에 올려 동료와 공유하면 협업으로 확장됩니다. 공유·협업은 GitHub 매뉴얼에서 다룹니다.

2. 브랜치 만들기·보기 (git branch)

git branch는 브랜치를 만들고, 보고, 지우고, 이름을 바꾸는 명령입니다. 주의할 점 하나: 인자 없이 git branch <이름>으로 브랜치를 만들면 생성만 되고 그쪽으로 이동하지는 않습니다. 이동까지 한 번에 하려면 다음 섹션의 git switch -c를 씁니다.

브랜치 목록 보기

git branch          # 로컬 브랜치 목록 (* 가 현재 브랜치)
git branch -a       # 원격(remote) 브랜치까지 포함한 전체 목록

브랜치 생성·이름 변경

git branch login        # 'login'이라는 새 브랜치 생성 (이동은 안 함)
git branch -m new-name  # 현재 브랜치의 이름을 'new-name'으로 변경

명령	하는 일
`git branch`	로컬 브랜치 목록 보기 (현재 위치는 `*`로 표시)
`git branch <이름>`	새 브랜치 생성 (현재 커밋 기준, 이동은 하지 않음)
`git branch -m <새이름>`	현재 브랜치의 이름 변경
`git branch -a`	원격 브랜치까지 포함한 전체 목록 보기
`git branch -d <이름>`	병합이 끝난 브랜치 삭제 (정리 섹션 참고)

git branch <이름>은 '만들기만' 합니다. 만든 직후 그 브랜치에서 작업하려면 git switch <이름>으로 이동해야 합니다. 한 번에 끝내려면 git switch -c <이름>이 편합니다.

3. 브랜치 이동 (git switch)

git switch는 브랜치 이동 전용 명령으로, 최신 Git에서 권장하는 방식입니다(예전엔 checkout이 이 일을 겸했습니다 — 7번 섹션 참고). 이름 그대로 '브랜치 전환'에만 집중하므로 헷갈릴 일이 적습니다.

기본 이동과 생성+이동

git switch main           # main 브랜치로 이동
git switch -c feature/login  # feature/login 브랜치를 만들면서 바로 이동
git switch -                 # 직전에 있던 브랜치로 되돌아가기

-c는 'create'의 약자로, 생성과 이동을 한 번에 합니다. 가장 자주 쓰게 될 형태입니다. git switch -는 두 브랜치를 오갈 때 유용합니다(cd -와 비슷한 감각).

명령	하는 일
`git switch <브랜치>`	해당 브랜치로 이동
`git switch -c <새브랜치>`	새 브랜치 생성 + 이동 (가장 흔함)
`git switch -C <브랜치>`	같은 이름이 있어도 강제로 새로 만들며 이동
`git switch -`	직전에 있던 브랜치로 이동
`git switch --detach <커밋>`	브랜치 없이 특정 커밋만 잠깐 살펴보기

로컬 변경이 있을 때

작업 폴더에 커밋하지 않은 변경이 남아 있으면, switch는 기본적으로 이동을 거부합니다. 이동하면서 그 변경이 사라질 수 있기 때문에, 실수로 작업을 잃지 않도록 막아 주는 것입니다.

권장 워크플로우: 변경이 있는데 다른 브랜치로 가야 할 때는, 먼저 git commit으로 저장하거나 git stash로 임시 보관한 뒤 브랜치를 이동하세요.

# 방법 1) 변경을 커밋으로 저장한 뒤 이동
git add .
git commit -m "작업 중 내용 저장"
git switch other-branch

# 방법 2) 변경을 임시 보관한 뒤 이동 (나중에 git stash pop으로 되살림)
git stash
git switch other-branch

-f(--discard-changes)는 커밋하지 않은 변경을 되돌릴 수 없게 버립니다. 대개는 먼저 git commit으로 저장하거나, 임시 보관(git stash) 후 이동하는 편이 안전합니다.

💡 원격에 같은 이름의 브랜치가 있다면? git switch <이름>은 기본값인 --guess 덕분에, 로컬에 없어도 원격 브랜치를 자동으로 추적하는 로컬 브랜치를 만들어 이동해 줍니다. 동료가 올린 브랜치를 받아 작업할 때 편리합니다.

4. 병합 (git merge)

git merge는 다른 브랜치의 변경을 현재 브랜치로 합치는 명령입니다. 핵심은 "어디로 합칠지(현재 브랜치) 먼저 이동한 뒤, 무엇을 가져올지(인자) 지정한다"는 순서입니다.

git switch main          # 1) 합쳐 '받을' 브랜치로 이동
git merge feature/login  # 2) feature/login의 변경을 main으로 가져와 합침

병합의 두 가지 방식

Git은 상황에 따라 두 가지 방식으로 합칩니다. 이 둘의 차이를 알면 git log --graph가 왜 그런 모양인지 이해됩니다.

Fast-forward (빨리 감기): 현재 브랜치가 갈라진 뒤로 새 커밋이 하나도 없을 때 일어납니다. 합칠 게 따로 없으니 현재 브랜치의 포인터를 그냥 앞으로 옮기기만 합니다. 병합 커밋이 새로 생기지 않습니다.
3-way merge (3방향 병합): 양쪽 브랜치가 모두 진행됐을 때 일어납니다. 두 갈래를 하나로 합치는 '병합 커밋(merge commit)'이 새로 만들어집니다.

병합 옵션

명령	하는 일
`git merge <브랜치>`	기본 병합 (상황에 따라 fast-forward 또는 3-way)
`git merge --no-ff <브랜치>`	fast-forward가 가능해도 항상 병합 커밋을 만듦 (이력에 갈래가 남음)
`git merge --squash <브랜치>`	변경을 합치되 커밋은 하지 않고 스테이징(인덱스)에만 올림. 이후 `git commit`으로 하나의 깔끔한 커밋을 직접 만들어야 함

📌 --no-ff는 "이 묶음이 하나의 기능 작업이었다"는 기록을 이력에 남기고 싶을 때, --squash는 자잘한 여러 커밋을 깔끔한 하나로 정리해 합치고 싶을 때 씁니다. 처음엔 옵션 없는 기본 git merge만 써도 충분합니다.

5. 충돌 해결 (Conflict)

충돌은 같은 파일의 같은 부분을 양쪽 브랜치가 서로 다르게 고쳤을 때 발생합니다. 이럴 땐 Git이 어느 쪽이 옳은지 판단할 수 없으므로 자동 병합을 멈추고, 사람에게 "직접 골라 달라"고 요청합니다. 충돌은 오류가 아니라 정상적인 협업의 한 과정입니다. 당황하지 말고 차근차근 풀면 됩니다.

충돌이 나면 파일은 어떻게 보이나

충돌이 난 파일을 열면 Git이 다음과 같은 충돌 마커를 끼워 넣어, 양쪽 버전을 나란히 보여 줍니다.

<<<<<<< HEAD
현재 브랜치(내가 있던 쪽)의 내용
=======
합치려는 브랜치 쪽의 내용
>>>>>>> feature/login

<<<<<<< HEAD ~ ======= : 현재 브랜치(HEAD) 쪽 코드
======= ~ >>>>>>> 브랜치명 : 합치려는 브랜치 쪽 코드

해결 절차

git status로 충돌이 난 파일 목록을 확인합니다.
파일을 열어 원하는 최종 코드로 직접 고치고, 세 줄의 마커(<<<<<<<, =======, >>>>>>>)를 모두 지웁니다.
해결한 파일을 git add <파일>로 스테이징합니다.
git commit으로 병합을 마무리합니다(메시지는 자동으로 채워집니다).

git status              # 어떤 파일이 충돌했는지 확인
# (편집기로 파일을 고치고 마커 삭제)
git add index.html      # 해결한 파일을 스테이징
git commit              # 병합 완료

병합을 그만두고 싶을 때

충돌이 너무 복잡하거나 지금 처리하기 어렵다면, 병합을 통째로 취소하고 병합 직전 상태로 되돌릴 수 있습니다.

git merge --abort       # 병합을 중단하고 합치기 전 상태로 복귀

마커를 지우지 않은 채 그대로 커밋하면, <<<<<<< 같은 기호가 코드에 그대로 섞여 버립니다. add 전에 마커가 모두 사라졌는지 꼭 확인하세요.

6. 브랜치 정리 (삭제·이름 변경)

역할을 다한 브랜치(병합이 끝난 기능 브랜치 등)는 정리해 두는 편이 좋습니다. 목록이 깔끔해야 지금 진행 중인 작업이 잘 보입니다.

브랜치 삭제

git branch -d feature/login   # 병합이 끝난 브랜치 삭제 (안전)
git branch -D feature/login   # 병합 여부와 상관없이 강제 삭제

명령	하는 일
`git branch -d <이름>`	병합이 끝난 브랜치 삭제. 아직 안 합쳐졌으면 경고하며 거부(안전장치)
`git branch -D <이름>`	병합 여부 무시하고 강제 삭제
`git branch -m <새이름>`	현재 브랜치의 이름 변경

대문자 -D는 합쳐지지 않은 커밋이 있어도 묻지 않고 지웁니다. 그 브랜치에만 있던 작업이 사라질 수 있으니, 정말 버려도 되는지 확인하고 쓰세요. 평소엔 소문자 -d를 권장합니다.

💡 지금 들어가 있는 브랜치는 삭제할 수 없습니다. 먼저 git switch main으로 다른 브랜치로 나온 뒤 삭제하세요.

7. checkout 구식 vs 신식 (switch · restore)

예전 Git에서는 git checkout 하나가 너무 많은 일을 했습니다. 브랜치 이동도, 파일 복구도 같은 명령으로 처리했기 때문에 입문자들이 자주 헷갈렸습니다.

# 예전 방식 — 한 명령이 두 가지 일을 함
git checkout main          # (브랜치 이동)
git checkout -- index.html # (파일을 마지막 커밋 상태로 복구)

그래서 Git 2.23부터 이 둘을 의미가 분명한 두 명령으로 나눴습니다.

하고 싶은 일	신식 (권장)	구식
브랜치 이동 / 생성+이동	권장`git switch <브랜치>`	구식`git checkout <브랜치>`
파일을 마지막 커밋 상태로 복구	권장`git restore <파일>`	구식`git checkout -- <파일>`

📌 git checkout은 지금도 똑같이 동작하므로, 다른 사람의 코드나 오래된 자료에서 자주 보게 됩니다. 다만 입문자는 "이동은 switch, 복구는 restore"로 외워 두면 의미가 헷갈리지 않습니다.

참고 링크

Git 2.54.0 기준 · 한국어 교육 자료 · 문서 수집일 2026년 6월 13일
공식 문서: git-scm.com/docs/git-branch