Git 브랜치와 병합 | "merge conflict 났어요" 충돌 해결 방법 (branch, merge)

· 18분 읽기 · 수정 초급 실습
Git 브랜치와 병합 | "merge conflict 났어요" 충돌 해결 방법 (branch, merge)

이 글의 핵심

Git 브랜치·병합·충돌 해결과 Git Flow·GitHub Flow·Trunk Based, merge/rebase 선택, IDE에서 충돌 해결, 브랜치 정리까지 실전 가이드입니다.

[Git 실전 가이드 #2] 브랜치와 병합

이전 글: Git 기초 입문(#1)에서 설치·커밋·스테이징·원격 기본을 다뤘습니다.

Git 브랜치(branch)는 같은 저장소 안에서 서로 다른 줄기의 작업선을 만드는 것입니다. 평행 세계를 하나 더 까는 것에 가깝습니다—같은 출발점에서 갈라졌다가, 나중에 merge로 두 세계의 변경을 한 줄기로 합칩니다. 새 기능은 main을 직접 바꾸지 않고 feature/login 같은 브랜치에서 만든 뒤, 완료 시 합치는 방식이 실무에서 흔합니다.

커밋은 그 줄기 위의 스냅샷이라고 보시면 됩니다. 브랜치 이름은 “어느 스냅샷을 가리키는지”를 가리키는 포인터에 가깝습니다.

브랜치·병합 흐름을 한눈에 보면 아래와 같습니다.

flowchart LR
  A[main] --> B[branch feature]
  B --> C[커밋 on feature]
  C --> D[checkout main]
  D --> E[merge feature]
  E --> F[main에 반영]

이 글에서는 브랜치 생성·전환·병합과 merge conflict 해결, fast-forward·3-way·--no-ff, merge와 rebase 선택, Git Flow·GitHub Flow·Trunk Based, IDE·바이너리 충돌, 기능·hotfix 시나리오, 브랜치 정리까지 정리합니다.

이 글을 읽으면:

  • git branch, git checkout, git merge를 올바르게 사용할 수 있습니다.
  • 병합 충돌이 났을 때 해결하는 방법을 알 수 있습니다.
  • 팀에서 쓰는 브랜치 전략(Git Flow, GitHub Flow, Trunk Based)과 네이밍·워크플로를 이해할 수 있습니다.
  • Fast-forward와 3-way 병합, --no-ff, merge와 rebase 선택 기준을 구분할 수 있습니다.
  • IDE에서 충돌을 해결하고, 기능·hotfix·다인 수정 시나리오에 적용할 수 있습니다.

목차

  1. 브랜치란 무엇인가
  2. 브랜치 생성과 전환
  3. 병합(merge)하기
  4. 병합 심화: fast-forward, 3-way, --no-ff, merge vs rebase
  5. merge conflict 해결
  6. 충돌 해결 실전: 마커 읽기, IDE, 바이너리
  7. 실무 브랜치 전략
  8. 실전 시나리오
  9. 브랜치 관리: 정리·원격 삭제·이름 변경
  10. 자주 묻는 질문 (FAQ)

1. 브랜치란 무엇인가

왜 브랜치를 쓰나요?

  • main(또는 master)은 “배포 가능한 안정 버전”으로 두고, 새 기능·버그 수정은 별도 브랜치에서 합니다.
  • 여러 사람이 동시에 다른 작업을 해도 서로 덮어쓰지 않고, 나중에 병합(merge)으로 합칩니다.
  • “이 커밋부터 갈라져 나온 작업선”이 브랜치이고, HEAD(현재 체크아웃된 커밋·브랜치를 가리키는 포인터)가 가리키는 브랜치가 “지금 작업 중인 브랜치”입니다.

브랜치 확인

# 복사해 붙여넣은 뒤: Git 저장소 폴더에서 터미널 실행
git branch
# * main
#   feature/login

실행 결과: *가 붙은 것이 현재 브랜치입니다. 새 폴더라면 git init 후 git branch를 실행하면 * main만 보입니다. git branch만 실행하면 로컬 브랜치 목록이 나옵니다.

2. 브랜치 생성과 전환

새 브랜치 만들기

브랜치를 만드는 두 가지 방법입니다:

# 방법 1: 브랜치만 생성 (전환하지 않음)
git branch feature/login
# 동작:
# - 현재 커밋을 가리키는 "feature/login"이라는 포인터 생성
# - HEAD는 여전히 현재 브랜치를 가리킴 (이동하지 않음)
# - 브랜치 이름만 만들고 작업은 현재 브랜치에서 계속

# 브랜치 목록 확인
git branch
# 출력 예시:
# * main              (* 표시: 현재 브랜치)
#   feature/login

# 방법 2: 생성과 동시에 그 브랜치로 전환 (실무에서 자주 씀)
git checkout -b feature/login
# 동작:
# 1. "feature/login" 브랜치 생성 (git branch feature/login)
# 2. 해당 브랜치로 전환 (git checkout feature/login)
# 3. HEAD가 feature/login을 가리킴
# 
# 출력: Switched to a new branch 'feature/login'

# 최신 Git 명령 (v2.23+)
git switch -c feature/login
# switch: checkout의 브랜치 전환 기능만 분리
# -c: create (브랜치 생성)
# 더 직관적이고 안전함 (파일 복원과 혼동 없음)

브랜치 생성 시점:

  • 새 기능 개발 시작 전
  • 버그 수정 작업 전
  • 실험적인 변경 시도 전

브랜치 명명 규칙:

feature/user-login      # 새 기능
bugfix/crash-on-save    # 버그 수정
hotfix/security-patch   # 긴급 수정
refactor/database       # 리팩토링

git branch <이름>은 “현재 커밋을 기준으로 새 브랜치 이름만 만든다”는 뜻입니다. git checkout -b <이름>은 “새 브랜치를 만들고 바로 그 브랜치로 이동”하므로, 새 기능을 시작할 때 거의 항상 이렇게 씁니다. 최신 Git에서는 git switch -c feature/login으로도 같은 동작을 할 수 있습니다.

브랜치 전환

git checkout feature/login
# 또는
git switch feature/login

다른 브랜치로 넘어가면 작업 디렉터리의 파일이 그 브랜치의 상태로 바뀝니다. 수정 중인 파일이 있으면 충돌 가능성이 있어 경고가 나올 수 있으므로, 전환 전에 커밋하거나 stash하는 것이 안전합니다.

3. 병합(merge)하기

Fast-forward 병합

현재 브랜치(main)가 가리키는 커밋 뒤에, 병합할 브랜치(feature/login)의 커밋이 직선으로 이어져 있으면 fast-forward 병합이 됩니다. 이때는 “포인터만 앞으로 이동”하므로 별도 병합 커밋이 생기지 않습니다.

# 상황: main에서 feature/login 브랜치를 만들고 작업
#       main은 그대로, feature/login에만 커밋 추가됨
# 
# 커밋 그래프:
# main → A → B
#             ↓
#             feature/login → C → D
# 
# main은 B를 가리키고, feature/login은 D를 가리킴

# 1. main 브랜치로 전환
git checkout main
# HEAD가 main을 가리킴

# 2. feature/login 병합
git merge feature/login
# 
# 출력 예시:
# Updating abc1234..def5678
# Fast-forward
#  login.js | 10 ++++++++++
#  1 file changed, 10 insertions(+)
# 
# 동작:
# - Git이 "main이 feature/login의 조상"임을 감지
# - main 포인터를 feature/login이 가리키는 D로 이동
# - 새 커밋 생성 없음 (포인터만 이동)
# 
# 결과 그래프:
# A → B → C → D
#             ↑
#             main, feature/login (둘 다 D를 가리킴)

# Fast-forward를 원하지 않으면 (병합 커밋 강제 생성)
git merge --no-ff feature/login
# --no-ff: no fast-forward
# 항상 병합 커밋을 생성하여 브랜치 이력 보존

Fast-forward가 가능한 조건:

  • main 브랜치에 새 커밋이 없음
  • feature 브랜치가 main의 직계 후손

Fast-forward의 장단점:

  • 장점: 이력이 깔끔함 (일직선)
  • 단점: 브랜치가 존재했다는 기록이 사라짐

3-way merge (병합 커밋 생성)

main과 feature 둘 다 각각 새 커밋이 있으면, “두 브랜치의 변경을 합친 병합 커밋”이 하나 생성됩니다.

# 상황: main과 feature/login이 각각 독립적으로 커밋 추가
# 
# 커밋 그래프:
#       C (feature/login)
#      /
# A → B
#      \
#       D (main)
# 
# 공통 조상: B
# main: B → D
# feature/login: B → C

# 1. main 브랜치로 전환
git checkout main
# 현재 main은 D를 가리킴

# 2. feature/login 병합
git merge feature/login -m "Merge branch 'feature/login' into main"
# 
# 출력 예시:
# Merge made by the 'ort' strategy.
#  login.js | 10 ++++++++++
#  1 file changed, 10 insertions(+)
# 
# 동작 (3-way merge):
# 1. 공통 조상 커밋 B를 찾음
# 2. B → C의 변경사항 파악
# 3. B → D의 변경사항 파악
# 4. 두 변경사항을 합친 새 커밋 E 생성
# 
# 결과 그래프:
#       C ─────┐
#      /       ↓
# A → B → D → E (main, 병합 커밋)
#      \     ↗
#       D ──┘
# 
# E는 부모가 2개 (C와 D)인 병합 커밋

# 메시지 생략 시 (에디터가 열림)
git merge feature/login
# 기본 메시지:
# Merge branch 'feature/login' into main
# 
# 에디터에서 메시지를 수정하거나 그대로 저장

3-way merge가 필요한 경우:

  • main과 feature 둘 다 새 커밋이 있음
  • 두 브랜치가 갈라진 상태

병합 커밋의 특징:

  • 부모 커밋이 2개 (양쪽 브랜치)
  • 브랜치 이력이 보존됨
  • git log --graph로 시각화 가능

병합 취소 (아직 push 안 했을 때)

git merge --abort

병합 중 충돌이 났을 때 “일단 병합을 취소하고 예전 상태로 돌아가겠다”면 git merge —abort를 사용합니다. 충돌을 해결하기 전에 상태를 되돌릴 때 유용합니다.

4. 병합 심화: fast-forward, 3-way, --no-ff, merge vs rebase

앞에서 다룬 내용을 한 줄로 정리하면 다음과 같습니다.

구분Fast-forward3-way merge
조건대상 브랜치에 새 커밋이 없고, 병합할 쪽이 직선 후손양쪽 모두 공통 조상 이후에 서로 다른 커밋이 있음
결과포인터만 이동, 병합 커밋 없음병합 커밋 하나가 생김
이력가장 단순한 일직선분기와 합치기가 그래프에 남음

merge --no-ff를 쓰는 이유

Fast-forward가 가능한 상황에서도 git merge --no-ff feature/login을 쓰면, 항상 병합 커밋이 만들어집니다. 이렇게 하면:

  • 기능 단위 묶음이 한 커밋(병합 커밋)으로 보이고, git log --first-parent main으로 “main 위주” 이력을 읽기 쉽습니다.
  • 나중에 해당 기능을 revert할 때 병합 커밋 하나를 되돌리는 식으로 처리하기 수월한 경우가 많습니다.

반대로 팀이 최대한 단순한 일직선 이력을 선호하면 Fast-forward를 그대로 두는 편이 맞습니다. 규칙은 팀 합의가 우선입니다.

merge vs rebase 선택 기준

  • merge
    • 이미 여러 사람이 pull한 브랜치에 안전하게 합칠 때 기본 선택입니다.
    • 공개 이력을 덮어쓰지 않고 분기 구조를 보존합니다.
  • rebase
    • 아직 push하지 않았거나, 팀 규칙상 “내 커밋만 base 위로 재배치해도 된다”고 한 개인 작업 브랜치에서 자주 씁니다.
    • 결과적으로 커밋이 재작성되므로, 이미 공유된 브랜치에 임의로 rebase하면 다른 사람의 클론과 충돌합니다.

실무 규칙으로 많이 쓰는 패턴: main에 넣을 때는 PR에서 squash merge 또는 merge commit으로 통합하고, 로컬에서만 rebase로 정리한다. 자세한 rebase·되돌리기는 Git 되돌리기·rebase(#4)를 참고하세요.

5. merge conflict 해결

충돌이 나는 상황

같은 파일의 같은 부분을 서로 다른 브랜치에서 수정한 뒤 병합하면, Git이 “어느 쪽을 쓸지” 자동으로 결정하지 못해 merge conflict가 납니다.

충돌 시 나타나는 표시

충돌이 난 파일을 열면 다음과 같은 마커가 보입니다:

<<<<<<< HEAD
main 브랜치에서 수정한 내용
=======
feature 브랜치에서 수정한 내용
>>>>>>> feature/login
  • <<<<<<< HEAD: 현재 브랜치(main)의 내용
  • =======: 구분선
  • >>>>>>> feature/login: 가져오는 브랜치의 내용

해결 절차

  1. 충돌한 파일을 편집기로 열어 위 마커 전체를 지우고, 남기고 싶은 코드(또는 둘을 합친 결과)만 남깁니다.
  2. 저장한 뒤 해당 파일을 스테이징합니다.
    git add <파일명>
  3. 모든 충돌 파일을 처리했으면 병합 커밋을 완료합니다.
    git commit
    (메시지는 기본으로 채워져 있음)
# 1. 파일 수정 후
git add conflicted_file.cpp
git commit -m "Resolve merge conflict in conflicted_file.cpp"

git status로 “Unmerged paths”가 없어지면 충돌을 다 처리한 것입니다. 그다음 git commit으로 병합을 마칩니다.

5. 실무 브랜치 전략

Git Flow 요약

  • main: 배포 가능한 안정 버전
  • develop: 다음 배포를 위한 통합 브랜치
  • feature/기능명: 새 기능 개발 (develop에서 갈라져 나와 develop에 병합)
  • release/버전: 배포 준비 (버그 수정만)
  • hotfix/설명: 긴급 수정 (main에서 갈라져 main·develop에 병합)

작은 팀이나 레포 하나만 있을 때는 main + feature 브랜치만 써도 충분한 경우가 많습니다. 다음 글(#3)에서 원격 저장소와 push/pull을 다루면, 팀원과 브랜치를 공유하는 방법까지 이어집니다.

6. 자주 묻는 질문 (FAQ)

Q. git merge와 git rebase 차이는?

A. merge는 “두 브랜치를 합친 병합 커밋”을 만듭니다. rebase는 한 브랜치의 커밋을 다른 브랜치 끝에 “다시 올려붙여” 이력이 한 줄로 보이게 합니다. 이미 원격에 push한 브랜치를 rebase하면 이력이 바뀌어 협업 시 문제가 될 수 있으므로, 로컬·아직 push 안 한 브랜치에서만 rebase를 쓰는 것이 안전합니다. 자세한 rebase 사용법은 Git 되돌리기·rebase(#4)에서 다룹니다.

Q. 병합 후 브랜치를 삭제해도 되나요?

A. 병합이 끝난 로컬 브랜치는 git branch -d feature/login으로 삭제해도 됩니다. 이미 병합된 내용은 main에 있으므로 사라지지 않습니다. 원격 브랜치는 GitHub/GitLab에서 “Delete branch”로 지우거나, git push origin —delete feature/login으로 삭제할 수 있습니다.

Q. 실무에서 브랜치 이름은 어떻게 짓나요?

A. 팀 규칙을 따르는 것이 좋습니다. 자주 쓰는 예: feature/기능명, fix/버그설명, hotfix/긴급수정. 소문자·숫자·하이픈만 쓰면 URL이나 로그에서 다루기 쉽습니다.

마무리

  • 브랜치: 독립된 작업선. git checkout -b 또는 git switch -c로 생성·전환.
  • 병합: git checkout main 후 git merge로 합침. Fast-forward 또는 3-way 병합 커밋; 이력을 남기려면 —no-ff.
  • merge vs rebase: 공유 브랜치는 merge가 기본, 로컬 정리는 rebase를 팀 규칙에 맞게.
  • 충돌: 마커를 제거하고 최종 내용만 남긴 뒤 git add → git commit. 바이너리는 —ours / —theirs로 한쪽 선택.
  • 전략: Git Flow / GitHub Flow / Trunk Based 중 팀에 맞는 모델과 feature·bugfix·hotfix 네이밍을 맞춥니다.
  • 관리: 병합된 로컬 브랜치는 git branch -d, 원격은 git push origin —delete 또는 fetch —prune으로 정리.

다음 글: Git 실전 가이드 #3: 원격 저장소와 협업 — push, pull, PR, 협업 워크플로

이전 글: Git 실전 가이드 #1: Git 기초 입문

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

  • Git 기초 입문 [#1] — 설치·커밋·브랜치·원격 저장소 한 번에
  • Git push pull 차이 | 원격 저장소·GitHub 협업·Pull Request 완벽 가이드
  • Git 실전 가이드 시리즈 목차 | 기초·브랜치·원격·rebase

실전 팁

실무에서 바로 적용할 수 있는 팁입니다.

디버깅 팁

  • 문제가 발생하면 먼저 컴파일러 경고를 확인하세요
  • 간단한 테스트 케이스로 문제를 재현하세요

성능 팁

  • 프로파일링 없이 최적화하지 마세요
  • 측정 가능한 지표를 먼저 설정하세요

코드 리뷰 팁

  • 코드 리뷰에서 자주 지적받는 부분을 미리 체크하세요
  • 팀의 코딩 컨벤션을 따르세요

실전 체크리스트

실무에서 이 개념을 적용할 때 확인해야 할 사항입니다.

코드 작성 전

  • 이 기법이 현재 문제를 해결하는 최선의 방법인가?
  • 팀원들이 이 코드를 이해하고 유지보수할 수 있는가?
  • 성능 요구사항을 만족하는가?

코드 작성 중

  • 컴파일러 경고를 모두 해결했는가?
  • 엣지 케이스를 고려했는가?
  • 에러 처리가 적절한가?

코드 리뷰 시

  • 코드의 의도가 명확한가?
  • 테스트 케이스가 충분한가?
  • 문서화가 되어 있는가?

이 체크리스트를 활용하여 실수를 줄이고 코드 품질을 높이세요.

이 글에서 다루는 키워드 (관련 검색어)

Git, 브랜치, 병합, merge, branch, checkout, Git브랜치, merge conflict, 충돌해결, 브랜치전략 등으로 검색하시면 이 글이 도움이 됩니다.

관련 글

  • C++ Branch Prediction
  • C++ STL 고급 알고리즘 | partition·merge·집합 연산·힙으로 데이터 처리 마스터
  • Git 기초 입문 [#1] — 설치·커밋·브랜치·원격 저장소 한 번에
  • Git push pull 차이 | 원격 저장소·GitHub 협업·Pull Request 완벽 가이드
  • Git 되돌리기