Git 병합 완벽 가이드 — 충돌 해결부터 예방까지 실무 노하우

💻 Git 머지, 왜 이렇게 헷갈릴까요?

팀 프로젝트에서 Git을 쓰다 보면 피할 수 없는 순간이 옵니다. 바로 병합(Merge) 충돌입니다. 혼자 개발할 땐 문제가 없지만, 여러 개발자가 같은 파일을 동시에 수정하는 순간 Git은 충돌 신호를 보냅니다. 어떤 코드를 남기고 어떤 코드를 버려야 할지 막막해지는 경험, 한 번쯤 해보셨을 겁니다.

이 강의는 Git 병합의 내부 작동 원리부터 CLI와 VS Code를 활용한 실전 충돌 해결, merge와 rebase의 근본적인 차이, 그리고 충돌을 사전에 예방하는 팀 협업 지침까지 한 번에 다룹니다.

📚 무엇을 배우나요?

• 패스트 포워드(Fast-Forward) 병합: 가장 단순한 병합 방식의 원리와 언제 발생하는지 이해
• 3자 병합(3-Way Merge): 두 브랜치가 분기된 이후 병합되는 메커니즘 심층 분석
• Merge vs Rebase: 히스토리 구조가 어떻게 달라지는지, 각각 언제 선택해야 하는지
• 충돌(Conflict) 발생 원리: Git이 어떤 상황에서 충돌을 선언하는지, 충돌 마커 읽는 법
• CLI에서 충돌 해결: 터미널만으로 빠르게 충돌을 처리하는 4단계 실전 절차
• VS Code에서 충돌 해결: 시각적 diff 도구로 Current·Incoming·Both 선택 해결
• 병합 되돌리기: git merge --abort로 병합 시작 전 상태로 안전하게 복귀하는 법
• 충돌 최소화 실무 예방 지침: 브랜치 전략, 작은 커밋, 자주 pull하는 습관 등

🔀 Merge vs Rebase, 히스토리 구조부터 다릅니다

merge와 rebase는 둘 다 "브랜치를 합친다"는 목적은 같지만, 결과로 남는 커밋 히스토리의 모양이 완전히 다릅니다. 이 차이를 모르고 팀에서 섞어 쓰면 히스토리가 뒤죽박죽되기 쉽습니다.

merge는 두 브랜치의 변경 이력을 그대로 보존한 채, 두 부모를 가진 "병합 커밋(merge commit)"을 새로 하나 만듭니다. 누가 언제 어떤 브랜치에서 작업했는지가 히스토리 그래프(git log --oneline --graph --all)에 갈래갈래 남습니다. 반면 rebase는 내 브랜치의 커밋들을 통째로 들어서, 대상 브랜치의 최신 커밋 뒤에 다시 쌓습니다. 결과적으로 마치 처음부터 순서대로 커밋한 것처럼 히스토리가 일직선으로 정리됩니다.

구분	Merge	Rebase
히스토리 형태	브랜치 분기가 그대로 남는 그래프형	커밋을 재배치한 일직선형
새로 생기는 커밋	병합 커밋(merge commit) 1개 추가	기존 커밋들이 새 해시로 재작성됨
충돌 처리 시점	병합 시점에 한 번에 발생	재배치되는 커밋마다 순차적으로 발생할 수 있음
이미 공유(push)된 브랜치	안전 — 원본 커밋을 건드리지 않음	위험 — 커밋 해시가 바뀌어 팀원 히스토리와 충돌 가능
주로 쓰는 상황	main·develop 같은 공용 브랜치 통합	PR 올리기 전 내 기능 브랜치 정리

실무 원칙은 간단합니다. 이미 원격에 push되어 다른 사람이 pull 받았을 가능성이 있는 브랜치는 rebase하지 않습니다. 커밋 해시가 바뀌면 팀원의 로컬 히스토리와 어긋나 강제 push(force push) 사고로 이어지기 쉽기 때문입니다. 반대로 아직 나만 보고 있는 로컬 기능 브랜치는 rebase로 커밋을 정리한 뒤 깔끔한 히스토리로 PR을 올리는 것이 좋은 습관입니다.

⚠️ 충돌(Conflict)은 왜, 어떻게 발생할까요?

Git은 3자 병합(3-way merge) 알고리즘을 씁니다. 두 브랜치의 최신 커밋만 비교하는 게 아니라, 두 브랜치가 갈라지기 전 공통 조상(common ancestor) 커밋까지 함께 놓고 3개의 버전을 비교합니다. 이때 같은 파일의 같은 줄이 두 브랜치에서 서로 다르게 수정되어 있으면, Git은 어느 쪽이 맞는지 자동으로 판단할 수 없어 충돌을 선언하고 사람에게 판단을 넘깁니다. 반대로 서로 다른 줄, 혹은 같은 방향으로 수정된 줄이라면 Git이 알아서 병합해 줍니다.

충돌이 나면 Git은 파일 안에 충돌 마커(conflict marker)를 직접 삽입해 둡니다. 실제로 파일을 열어보면 이런 모습입니다.

<<<<<<< HEAD
const greeting = "안녕하세요, 누구나패스입니다";
=======
const greeting = "환영합니다! 누구나패스에 오신 것을 환영해요";
>>>>>>> feature/welcome-message

마커를 읽는 법은 다음과 같습니다.

• <<<<<<< HEAD ~ ======= 사이 : 현재 내가 있는 브랜치(HEAD)의 내용
• ======= ~ >>>>>>> 브랜치명 사이 : 병합해 들어오는 상대 브랜치의 내용
• >>>>>>> 뒤에 적힌 이름 : 충돌을 일으킨 상대 브랜치(또는 커밋)의 이름

이 세 개의 기호(<<<<<<<, =======, >>>>>>>)는 반드시 사람이 직접 지우고 최종 코드만 남겨야 합니다. 이 마커를 실수로 남긴 채 커밋하면 문법 오류나 런타임 에러로 이어지므로, 커밋 전에 마커가 남아있지 않은지 항상 확인해야 합니다.

🛠 충돌 해결 실전 4단계

충돌이 발생했을 때 당황하지 않고 따라갈 수 있는 표준 절차입니다. CLI 기준으로 정리했습니다.

# 1단계: 충돌 상태와 충돌 파일 목록 확인
git status

# → "both modified: src/App.js" 처럼 표시된 파일이 충돌 파일입니다

# 2단계: 충돌 파일을 직접 열어 마커를 확인하고 수정
# (에디터로 <<<<<<<, =======, >>>>>>> 마커를 지우고
#  최종적으로 남길 코드만 남깁니다)

# 3단계: 해결한 파일을 스테이징
git add src/App.js

# 여러 파일이 충돌났다면 전체를 한 번에 추가해도 됩니다
git add .

# 4단계: 병합 커밋 생성 (메시지는 Git이 자동으로 채워줍니다)
git commit

여기서 중요한 점은, git add는 "충돌이 해결됐다"고 Git에게 알려주는 신호라는 것입니다. 마커를 지우지 않은 채로 add를 해도 Git은 막지 않으므로, add 하기 전에 반드시 파일 내용을 눈으로 확인하는 습관이 필요합니다. git status를 다시 실행해 "All conflicts fixed" 메시지가 뜨는지 확인한 뒤 commit 하면 안전합니다.

🧹 되돌리고 싶다면: git merge --abort

충돌을 해결하다가 "이건 아니다, 처음부터 다시 하자" 싶을 때가 있습니다. 이럴 땐 무리해서 수동으로 되돌리지 말고 아래 명령 한 줄로 병합 시작 전 상태로 완전히 복귀할 수 있습니다.

git merge --abort

이 명령은 병합 과정에서 변경된 모든 파일을 병합 시작 직전 상태로 되돌리고, 진행 중이던 병합 자체를 취소합니다. 단, 병합이 시작된 이후(충돌이 발생한 이후)에만 사용할 수 있습니다. 이미 commit까지 끝낸 병합을 되돌리고 싶다면 git reset --hard ORIG_HEAD 또는 git revert -m 1 <병합커밋해시>를 사용해야 하며, 이 부분은 상황에 따라 팀 컨벤션을 먼저 확인하는 것이 안전합니다.

비슷하게 rebase 도중 되돌리고 싶다면 git rebase --abort, 잠시 중단하고 나중에 이어가고 싶다면 git rebase --skip 또는 git merge --continue / git rebase --continue를 사용합니다.

🖥 병합 도구(Merge Tool) 활용하기

충돌 파일이 길거나 여러 곳에서 동시에 발생했다면, 텍스트만 보고 수동으로 지우는 것보다 시각적 도구를 쓰는 편이 훨씬 빠르고 안전합니다.

• VS Code 내장 병합 편집기: 충돌 파일을 열면 상단에 "Accept Current Change / Accept Incoming Change / Accept Both Changes / Compare Changes" 버튼이 자동으로 표시됩니다. 클릭 한 번으로 원하는 쪽을 선택하거나 두 변경을 모두 반영할 수 있어, 마커를 손으로 지우는 실수를 줄여줍니다.
• Source Control 패널: 왼쪽 사이드바의 Source Control 탭에서 "Merge Changes" 항목에 충돌 파일이 따로 모여 표시되므로, 여러 파일이 충돌났을 때 빠짐없이 처리할 수 있습니다.
• git mergetool 명령: CLI 환경에서도 git mergetool을 실행하면 설정된 외부 diff 도구(VS Code, KDiff3, Meld 등)가 자동으로 열립니다. git config --global merge.tool vscode로 VS Code를 기본 병합 도구로 등록해 두면 편리합니다.

어떤 도구를 쓰든 최종 목표는 동일합니다. 충돌 마커가 파일에 하나도 남지 않은 상태로, 코드가 실제로 정상 동작하는 형태로 정리하는 것입니다. 도구는 실수를 줄여줄 뿐, 최종 판단(어느 코드가 맞는지)은 항상 사람이 해야 합니다.

✅ 충돌을 예방하는 5가지 습관

충돌은 완전히 없앨 수는 없지만, 팀의 작업 습관에 따라 빈도와 크기를 크게 줄일 수 있습니다.

• 자주 pull(또는 rebase)하기: 내 브랜치를 하루 이상 방치하지 않고, 최소 하루 한 번은 git pull 또는 git fetch && git rebase origin/main으로 최신 변경을 반영합니다. 격차가 벌어질수록 충돌 범위도 커집니다.
• 작은 단위로 자주 커밋하기: 하나의 커밋·PR이 다루는 파일과 줄 수가 적을수록, 다른 사람과 겹칠 확률과 충돌 규모가 줄어듭니다. "기능 하나 = 커밋 하나"를 지키는 것만으로도 충돌 해결이 훨씬 쉬워집니다.
• 브랜치 수명을 짧게 유지하기: 브랜치를 오래 살려둘수록 main과의 차이가 벌어져 병합이 어려워집니다. 며칠 내로 머지하는 것을 원칙으로 삼으면 충돌 자체가 줄어듭니다.
• 팀 커뮤니케이션: 같은 파일(특히 설정 파일, 공통 컴포넌트, 라우터)을 여러 명이 동시에 손댈 예정이라면 미리 스레드나 스탠드업에서 공유합니다. 코드로 만나기 전에 말로 조율하는 것이 가장 빠른 예방책입니다.
• 포맷터·린터 설정 통일: 팀원마다 들여쓰기·줄바꿈 스타일이 다르면 실제 로직은 같아도 "충돌"로 잡히는 경우가 많습니다. Prettier·ESLint 같은 포맷터를 팀 전체가 동일하게 적용하면 불필요한 형식 충돌을 크게 줄일 수 있습니다.

💼 이런 분께 추천합니다

• Git을 쓰기 시작했지만 병합 충돌이 무서워서 피하고 있는 주니어 개발자
• 팀 프로젝트에서 충돌이 생길 때마다 시니어에게 SOS를 보내는 분
• CLI는 쓸 수 있지만 VS Code의 Git 도구를 제대로 활용하지 못하는 분
• 충돌을 해결할 순 있지만 원리를 이해하고 싶은 분
• merge와 rebase 중 언제 무엇을 써야 할지 헷갈리는 분
• 코딩 부트캠프 수료 후 실무 Git 협업이 걱정되는 분

💡 수강 정보

항목	내용
수강료	무료
강의 구성	1강 집중 완성
수강 대상	Git 기초를 아는 개발자 (입문~중급)
실습 환경	CLI(터미널) + VS Code
강사	누구나패스

❓ 자주 묻는 질문 (FAQ)

• Q. Git을 처음 배우는 분도 들을 수 있나요?
  commit, push, pull, branch 등 기본 개념을 이미 아는 분께 맞는 강의입니다. Git 완전 입문자라면 기초 강의를 먼저 수강하시길 권장합니다.
• Q. CLI가 익숙하지 않아도 괜찮나요?
  괜찮습니다. VS Code의 시각적 도구를 활용한 방법도 함께 다루기 때문에 CLI가 불편하더라도 충분히 따라오실 수 있습니다.
• Q. 충돌이 발생했을 때 무조건 내 코드만 남겨야 하나요?
  아닙니다. 상황에 따라 내 변경사항만 남기거나, 상대방 것만 남기거나, 두 코드를 합치는 방식 모두 가능합니다. 이 강의에서 각 케이스를 구체적으로 다룹니다.
• Q. rebase와 merge의 차이는 무엇인가요?
  이 페이지의 "Merge vs Rebase" 섹션에서 다뤘듯, merge는 병합 커밋을 추가해 분기 히스토리를 그대로 보존하고, rebase는 커밋을 재배치해 일직선 히스토리를 만듭니다. 이미 공유된 브랜치는 rebase하지 않는 것이 원칙입니다.
• Q. git add를 했는데 충돌 마커가 그대로 남아있으면 어떻게 되나요?
  Git은 마커가 남아있어도 add·commit을 막지 않습니다. 그대로 커밋되면 문법 오류나 버그로 이어질 수 있으므로, add 전에 파일을 열어 <<<<<<<, =======, >>>>>>> 마커가 남아있지 않은지 반드시 확인해야 합니다.
• Q. 병합을 시작했는데 취소하고 싶어요. 어떻게 하나요?
  커밋 전이라면 git merge --abort 한 줄로 병합 시작 전 상태로 안전하게 되돌릴 수 있습니다. 이미 커밋까지 끝난 병합을 되돌리려면 git reset --hard ORIG_HEAD나 git revert -m 1을 상황에 맞게 사용해야 합니다.

🚀 지금 바로 무료로 시작하세요

Git 충돌이 더 이상 두렵지 않도록, 이 강의 하나로 병합의 원리와 실전 해결법을 모두 익혀보세요.

강의 자세히 보기 →