Git 브랜치와 병합 | 'merge conflict 났어요' 충돌 해결 방법 (branch, merge)
이 글의 핵심
Git 브랜치와 병합: "merge conflict 났어요" 충돌 해결 방법 (branch, mer…. Git 실전 가이드 2 브랜치와 병합·브랜치란 무엇인가.
[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. 브랜치란 무엇인가
왜 브랜치를 쓰나요?
- 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-forward | 3-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: 가져오는 브랜치의 내용
해결 절차
- 충돌한 파일을 편집기로 열어 위 마커 전체를 지우고, 남기고 싶은 코드(또는 둘을 합친 결과)만 남깁니다.
- 저장한 뒤 해당 파일을 스테이징합니다.
git add <파일명> - 모든 충돌 파일을 처리했으면 병합 커밋을 완료합니다.
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)
git status로 작업 트리·스테이징을 먼저 확인합니다. 무엇이 다음 커밋에 들어가는지 모른 채 명령을 치면 실수가 누적됩니다.- 문제가 생기면
git log --oneline과git branch -vv로 “지금 어느 커밋·브랜치인지”를 고정한 뒤diff로 원인을 좁힙니다. - 이미 푸시한 커밋을 되돌릴 때는
reset --force보다 팀 규칙에 따라revert가 안전한 경우가 많습니다.
실전 체크리스트 (Git)
스테이징·커밋
-
git diff/git diff --staged로 의도한 변경만 올라갔는가? - 토큰·키·대용량 바이너리가 포함되지 않았는가?
원격·병합
-
pull전에 로컬 작업을 정리했는가(stash·임시 브랜치)? - 충돌 해결 후 다시 빌드·테스트했는가?
공유 브랜치
- 히스토리를 다시 쓰기 전에 팀에 알렸는가?
이 글에서 다루는 키워드 (관련 검색어)
Git, 브랜치, 병합, merge, branch, checkout, Git브랜치, merge conflict, 충돌해결, 브랜치전략 등으로 검색하시면 이 글이 도움이 됩니다.
관련 글
- C++ Branch Prediction
- C++ STL 고급 알고리즘 | partition·merge·집합 연산·힙으로 데이터 처리 마스터
- Git 기초 입문 [#1] — 설치·커밋·브랜치·원격 저장소 한 번에
- Git push pull 차이 | 원격 저장소·GitHub 협업·Pull Request 완벽 가이드
- Git 되돌리기
심화 부록: 구현·운영 관점
이 부록은 앞선 본문에서 다룬 주제(「Git 브랜치와 병합 | ‘merge conflict 났어요’ 충돌 해결 방법 (branch, merge)」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.
내부 동작과 핵심 메커니즘
flowchart TD A[입력·요청·이벤트] --> B[파싱·검증·디코딩] B --> C[핵심 연산·상태 전이] C --> D[부작용: I/O·네트워크·동시성] D --> E[결과·관측·저장]
sequenceDiagram participant C as 클라이언트/호출자 participant B as 경계(런타임·게이트웨이·프로세스) participant D as 의존성(API·DB·큐·파일) C->>B: 요청/이벤트 B->>D: 조회·쓰기·RPC D-->>B: 지연·부분 실패·재시도 가능 B-->>C: 응답 또는 오류(코드·상관 ID)
- 불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
- 결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
- 경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
- 백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.
프로덕션 운영 패턴
| 영역 | 운영 관점 질문 |
|---|---|
| 관측성 | 요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가 |
| 안전성 | 입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가 |
| 신뢰성 | 재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가 |
| 성능 | 캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가 |
| 배포 | 롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가 |
| 용량 | 피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가 |
스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.
확장 예시: 엔드투엔드 미니 시나리오
앞선 본문 주제(「Git 브랜치와 병합 | ‘merge conflict 났어요’ 충돌 해결 방법 (branch, merge)」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.
- 입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
- 핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
- 실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
- 호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
- 부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.
handle(request):
ctx = newCorrelationId()
validated = validateSchema(request)
authorize(validated, ctx)
result = domainCore(validated)
persistOrEmit(result, idempotentKey)
recordMetrics(ctx, latency, outcome)
return result문제 해결(Troubleshooting)
| 증상 | 가능 원인 | 조치 |
|---|---|---|
| 간헐적 실패 | 레이스, 타임아웃, 외부 의존성, DNS | 최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검 |
| 성능 저하 | N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스 | 프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거 |
| 메모리 증가 | 캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납 | 상한·TTL·힙/FD 스냅샷 비교 |
| 빌드·배포만 실패 | 환경 변수, 권한, 플랫폼 차이, lockfile | CI 로그와 로컬 diff, 런타임·이미지 버전 핀 |
| 설정 불일치 | 프로필·시크릿·기본값, 리전 | 스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화 |
| 데이터 불일치 | 비멱등 재시도, 부분 쓰기, 캐시 무효화 누락 | 멱등 키·아웃박스·트랜잭션 경계 재검토 |
권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.
배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.