Git 브랜치와 병합 이해하기: 3-way merge와 충돌까지

Об этом предложении

Git을 쓰는 가장 큰 이유 중 하나는 실패할 수 있는 작업을 안전하게 분리할 수 있다는 것 이다. 새 기능을 만들거나 실험적인 코드를 수정할 때 바로 main 에 작업하면 기존의 안정적인 상태까지 영향을 받을 수 있다. 이때 사용하는 것이 브랜치(branch) 다. 브랜치를 제대로 이해하면 기능 개발, 코드 리뷰, 협업, AI 코딩 에이전트 작업까지 같은 원리로 연결된다. 브랜치는 프로젝트 복사본이 아니다 처음에는 브랜치를 프로젝트 폴더 전체를 복사한 별도 사본처럼 생각하기 쉽다. 하지만 Git의 브랜치는 실제로는 특정 커밋을 가리키는 가벼운 포인터 에 가깝다. 현재 상태가 다음과 같다고 해보자. A ── B ── C ↑ main ↑ HEAD 여기서 새로운 브랜치를 만든다. git branch feature/login 그러면 main 과 feature/login 이 같은 C를 가리킨다. A ── B ── C ↑ main ↑ feature/login 브랜치로 이동한다. git switch feature/login 브랜치를 만들면서 바로 이동하려면 다음이 더 편하다. git switch -c feature/login 기존 방식으로는 다음 명령도 사용할 수 있다. git checkout -b feature/login 브랜치에서 커밋하면 해당 브랜치만 이동한다 feature/login 에서 커밋 D를 만들면 다음처럼 된다. A ── B ── C ── D ↑ ↑ main feature/login ↑ HEAD main 은 그대로 C에 있고 작업 브랜치만 D까지 이동했다. 이제 실험이 실패해도 main 은 영향을 받지 않는다. git switch main 다시 main으로 돌아오면 Working Directory도 main이 가리키는 버전에 맞게 바뀐다. 브랜치를 쓰면 "원본을 복사해 놓고 실패하면 되돌리기"라는 수동 작업을 Git이 훨씬 체계적으로 처리해준다. 브랜치 목록 확인과 삭제 현재 브랜치를 확인하려면 다음 명령을 사용한다. git branch 병합이 끝난 브랜치는 삭제할 수 있다. git branch -d feature/login Git이 아직 병합되지 않았다고 판단하는 브랜치를 강제로 삭제하려면 -D 를 사용할 수 있지만, 작업을 잃을 가능성이 있으므로 주의한다. git branch -D feature/login merge는 다른 브랜치의 작업을 현재 브랜치에 합친다 기능 개발이 성공했다면 main 으로 돌아온 뒤 병합한다. git switch main git merge feature/login 여기서 중요한 점은 어느 브랜치에서 merge를 실행했는가 다. git switch main git merge feature/login 이 명령은 " feature/login 의 변경을 현재 브랜치인 main 에 합친다"는 의미다. 즉 병합 대상과 병합 주체를 구분해야 한다. Fast-forward merge 브랜치를 만든 뒤 main에 새로운 커밋이 없다면 히스토리는 다음과 같다. A ── B ── C ── D ↑ ↑ main feature/login 이 상태에서 main이 feature/login을 병합하면 별도의 merge commit 없이 main 포인터만 D까지 이동할 수 있다. A ── B ── C ── D ↑ main, feature/login 이것이 Fast-forward merge 다. 브랜치가 갈라진 적은 있지만 main 쪽에서 별도 변경이 없기 때문에 "앞으로 이동"만 해도 결과가 같다는 뜻이다. 3-way merge는 왜 필요한가 이번에는 브랜치가 갈라진 뒤 양쪽에서 모두 커밋했다고 해보자. D ── E ← feature/login / A ── B ── C \ F ← main 이 경우 main은 단순히 feature/login으로 이동할 수 없다. 두 브랜치 모두 C 이후에 서로 다른 변경을 가지고 있기 때문이다. Git은 다음 세 지점을 비교한다. 두 브랜치의 공통 조상 C 현재 브랜치의 최신 상태 F 병합할 브랜치의 최신 상태 E 그래서 3-way merge 라고 부른다. 병합이 가능하면 Git은 두 변경을 함께 가진 새로운 merge commit을 만든다. D ── E / \ A ── B ── C M ← main \ / F ───── M은 두 부모 커밋을 가진다. 이 구조 때문에 "양쪽에서 각각 무엇이 바뀌었는지"를 공통 조상 기준으로 판단할 수 있다. 같은 파일을 수정했다고 무조건 충돌하는 것은 아니다 두 브랜치가 같은 파일을 수정했다고 해서 항상 충돌이 발생하는 것은 아니다. 예를 들어 공통 조상의 파일이 다음과 같다고 해보자. 1: title 2: content 3: footer main에서 2번째 줄을 수정하고, feature 브랜치에서 3번째 줄을 수정했다면 Git은 서로 다른 영역의 변경임을 파악해 자동으로 합칠 수 있다. main : 2번째 줄 수정 feature : 3번째 줄 수정 공통 조상 : 원래 상태 Git은 공통 조상을 기준으로 어느 쪽이 어떤 줄을 변경했는지 판단한다. conflict는 실패가 아니라 자동 결정할 수 없다는 신호다 충돌(conflict)은 보통 두 브랜치가 같은 부분을 서로 다르게 수정했을 때 발생한다. 예를 들어 두 브랜치 모두 같은 줄을 바꿨다고 하자. 공통 조상 button = "확인" main button = "저장" feature button = "완료" Git 입장에서는 저장 과 완료 중 무엇이 올바른지 판단할 수 없다. 이때 자동으로 잘못 합치는 대신 사람에게 결정을 넘긴다. 이것이 충돌이다. 즉 충돌은 "Git이 망가졌다"가 아니라 자동 병합하면 위험하기 때문에 멈춰 준 것 이다. 충돌 파일은 어떻게 보일까 충돌이 발생하면 파일 안에 다음과 비슷한 표시가 생길 수 있다. <<<<<<< HEAD button = "저장" ======= button = "완료" >>>>>>> feature/login 각 영역은 다음 의미를 가진다. HEAD 쪽: 현재 브랜치의 내용 구분선 아래: 병합하려는 브랜치의 내용 개발자가 최종 결과를 직접 선택하거나 새롭게 조합해야 함 예를 들어 최종 결과를 다음처럼 정할 수 있다. button = "저장 완료" 수정한 뒤 Git에게 "충돌을 해결했다"고 알려준다. git add app.js 그리고 병합 커밋을 완료한다. git commit Git GUI나 VS Code의 Merge Editor를 사용하면 양쪽 변경을 버튼으로 비교하며 해결할 수도 있다. 충돌 해결 흐름 실전에서는 다음 순서로 생각하면 된다. 1. merge 실행 2. conflict 발생 3. 충돌 파일 확인 4. 원하는 최종 코드로 수정 5. 테스트 6. git add 7. git commit 명령으로 보면 다음과 같다. git switch main git merge feature/login # 충돌 발생 후 파일 수정 git status git add src/login.js git commit 충돌 해결에서 중요한 것은 "양쪽 중 하나를 무조건 선택"하는 것이 아니다. 실제 비즈니스 요구와 코드 의도를 이해한 뒤 새로운 최종 결과를 만들어도 된다. 브랜치를 이용한 안전한 실험 패턴 새 기능을 바로 main에서 수정하기보다 다음 흐름이 안전하다. # 최신 main에서 시작 git switch main # 작업 브랜치 생성 git switch -c feature/search-filter # 코드 수정 git add . git commit -m "검색 필터 기능 추가" # 결과 확인 후 main으로 이동 git switch main # 성공한 작업 병합 git merge feature/search-filter # 필요하면 브랜치 정리 git branch -d feature/search-filter 실패했다면 병합하지 않고 브랜치를 버리면 된다. 이 방식은 사람뿐 아니라 AI 코딩 에이전트에게 실험적인 작업을 맡길 때도 유용하다. 메인 브랜치를 보호한 상태에서 별도 브랜치에서 작업하게 하고 결과를 검토한 뒤 병합하면 된다. 브랜치 이름을 읽기 쉽게 만들기 팀마다 규칙은 다르지만 브랜치의 목적이 바로 드러나는 이름이 좋다. feature/login feature/search-filter fix/payment-timeout docs/api-guide refactor/user-service 이슈 번호와 연결하는 팀이라면 다음처럼 사용할 수도 있다. feature/123-login fix/247-payment-timeout 정답이 하나 있는 것은 아니지만, 이름만 보고도 작업의 목적을 추측할 수 있어야 한다. 핵심 정리 브랜치는 프로젝트 복사본이 아니라 특정 커밋을 가리키는 가벼운 포인터 다. 브랜치에서 커밋하면 현재 브랜치만 새로운 커밋으로 이동한다. git merge <branch> 는 현재 브랜치에 대상 브랜치의 변경을 병합 한다. 한쪽만 앞으로 진행된 경우 Fast-forward merge가 가능하다. 양쪽 브랜치가 모두 변경되었다면 공통 조상까지 포함한 3-way merge 가 사용된다. 같은 파일을 수정해도 서로 다른 영역이면 자동 병합될 수 있다. conflict는 오류라기보다 Git이 안전하게 자동 결정할 수 없다는 신호 다. 충돌을 해결한 뒤 git add 와 git commit 으로 병합을 완료한다.