소프트웨어를 개발할 때는 메인 서비스를 유지하면서 동시에 새로운 기능을 추가하거나 버그를 수정하는 작업이 수시로 일어납니다. 만약 하나의 흐름(메인 코드베이스) 위에서 모든 개발자가 코드를 직접 수정한다면, 코드가 엉키고 완성되지 않은 기능이 서비스에 노출되는 등 끔찍한 문제가 발생할 것입니다. Git은 이러한 문제를 해결하기 위해 코드를 통째로 복사한 것처럼 독립적인 작업 환경을 제공하는 브랜치(Branch) 기능을 지원합니다.
이번 포스팅에서는 브랜치의 핵심 개념부터 생성, 이동, 그리고 삭제까지 브랜치 라이프사이클 전반에 대해 상세히 알아보겠습니다.

1. 브랜치(Branch)란 무엇인가?
브랜치를 우리말로 번역하면 '나뭇가지'입니다. Git에서의 브랜치는 나무의 기둥(메인 코드)에서 뻗어 나온 나뭇가지처럼, 기준이 되는 코드 흐름에서 분기하여 독립적으로 코드를 수정하고 테스트할 수 있는 가상의 작업 공간을 의미합니다.
특정 브랜치에서 코드를 수정하고 커밋하더라도 다른 브랜치에는 전혀 영향을 주지 않습니다. 이 덕분에 여러 개발자가 동시에 각자의 브랜치에서 로그인 기능 개발, 게시판 버그 수정, UI 디자인 변경 등을 안전하고 병렬적으로 진행할 수 있습니다. 각자의 작업이 완료된 후 검증이 끝나면 다시 메인 브랜치로 코드를 합치는(Merge) 방식으로 개발이 이루어집니다.
master (또는 main) 브랜치
`git init` 명령어로 저장소를 처음 생성하면, Git은 자동으로 `master`(최근에는 `main`을 권장)라는 이름의 기본 브랜치를 만듭니다. 별도의 브랜치를 생성하지 않으면 모든 커밋은 이 기본 브랜치 위에 쌓이게 됩니다. 실무에서 이 브랜치는 실제 사용자에게 배포되는 가장 안정적인 상태의 코드를 유지하는 역할을 합니다.
2. 브랜치 생성 및 확인: git branch
새로운 브랜치를 생성하거나, 현재 프로젝트에 어떤 브랜치들이 존재하는지 목록을 확인하려면 git branch 명령어를 사용합니다.
# 현재 브랜치 목록 확인
$ git branch
* master
# 'feature-login' 이라는 이름의 새로운 브랜치 생성
$ git branch feature-login
# 다시 브랜치 목록 확인
$ git branch
feature-login
* master
브랜치 목록을 보면 현재 위치해 있는 브랜치 앞에 * 기호가 붙어있고, 텍스트 색상이 다르게 표시됩니다. 새로운 브랜치를 만들었지만 여전히 현재 위치는 master 브랜치임을 알 수 있습니다.
3. 브랜치 이동 (전환): git checkout / git switch
작업할 공간(브랜치)을 변경하려면 git checkout 명령어를 사용합니다. (최신 Git 버전에서는 브랜치 전환에 특화된 git switch 명령어 사용을 권장합니다.) 이 명령어를 실행하면 워킹 디렉토리의 파일들이 해당 브랜치의 마지막 커밋 상태로 순식간에 변경됩니다.
# 'feature-login' 브랜치로 이동 (이전 방식)
$ git checkout feature-login
Switched to branch 'feature-login'
# 'feature-login' 브랜치로 이동 (최신 방식 권장)
$ git switch feature-login
Switched to branch 'feature-login'
# 상태 확인
$ git branch
* feature-login
master
브랜치 생성과 이동을 동시에 하기
실무에서는 브랜치를 만들자마자 바로 그 브랜치로 이동하는 경우가 대부분입니다. 이때는 -b(checkout) 또는 -c(switch) 옵션을 사용하여 두 과정을 하나로 단축할 수 있습니다.
# 'feature-pay' 브랜치 생성 및 동시 이동
$ git switch -c feature-pay
Switched to a new branch 'feature-pay'
4. 브랜치 삭제 및 이름 변경
기능 개발이 완료되어 메인 브랜치에 병합(Merge)이 끝났거나, 실험적으로 만들었다가 폐기하기로 결정한 브랜치는 삭제하여 목록을 깔끔하게 유지하는 것이 좋습니다.
# 'feature-pay' 브랜치 삭제 (-d 옵션)
# 주의: 삭제하려는 브랜치에 위치해 있으면 삭제할 수 없으므로 다른 브랜치로 이동 후 실행해야 합니다.
$ git switch master
$ git branch -d feature-pay
Deleted branch feature-pay (was a1b2c3d).
# 강제 삭제 (-D 옵션) : 병합되지 않은 변경사항이 있어도 강제로 지움
$ git branch -D feature-pay
브랜치의 이름을 변경하려면 -m 옵션을 사용합니다.
# 현재 위치한 브랜치의 이름을 'new-feature'로 변경
$ git branch -m new-feature
1. 브랜치 병합하기: git merge
브랜치를 병합할 때 가장 먼저 기억해야 할 원칙은 "내가 코드를 가져와서 합칠 기준 브랜치로 먼저 이동(Checkout/Switch)해야 한다"는 것입니다. 예를 들어, feature-login 브랜치의 작업 내역을 master 브랜치로 합치고 싶다면, 현재 위치를 master 브랜치로 변경한 뒤에 병합 명령어를 실행해야 합니다.
# 1. 기준이 되는 master 브랜치로 이동
$ git switch master
Switched to branch 'master'
# 2. feature-login 브랜치를 master로 병합
$ git merge feature-login
Updating a1b2c3d..e4f5g6h
Fast-forward
login.html | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
Fast-forward 병합이란?
위 예시의 결과를 보면 Fast-forward라는 단어가 나타납니다. feature-login 브랜치를 파생시킨 이후 master 브랜치에는 아무런 추가 커밋이 없었다면, Git은 별도의 병합 커밋(Merge Commit)을 새로 만들지 않고 단순히 master 브랜치의 포인터를 feature-login의 최신 커밋으로 이동시키기만 합니다. 이를 '빨리 감기(Fast-forward)' 병합이라고 부릅니다. 이 경우 히스토리가 일직선으로 매우 깔끔하게 유지됩니다.
3-way Merge (병합 커밋 생성)
반대로 feature-login 브랜치에서 작업하는 동안 다른 누군가가 master 브랜치에 코드를 반영하여, 두 브랜치가 서로 다른 방향으로 전진해버린 경우가 있습니다. 이때 git merge를 수행하면, Git은 공통 조상 커밋과 각 브랜치의 최신 커밋, 총 3개의 지점을 비교하여 새로운 병합 커밋(Merge Commit)을 자동으로 생성하며 두 흐름을 하나로 합칩니다.
2. 충돌(Conflict)의 발생과 원인
3-way Merge 과정에서, 두 브랜치가 서로 다른 파일을 수정했거나 동일한 파일이라도 서로 다른 부분을 수정했다면 Git이 알아서 코드를 잘 섞어줍니다. 하지만, 두 브랜치에서 동일한 파일의 정확히 같은 줄(Line)을 수정했다면 상황이 달라집니다. Git은 어떤 코드를 최종적으로 선택해야 할지 알 수 없으므로 자동 병합을 중단하고 사용자에게 충돌(Merge Conflict)이 발생했음을 알립니다.
# 충돌 발생 시의 터미널 화면
$ git merge feature-payment
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
위 메시지는 index.html 파일에서 충돌이 발생했으며, 사용자가 직접 코드를 수정한 뒤 다시 커밋하라는 의미입니다.
3. 충돌(Conflict) 해결하기
충돌이 발생한 파일을 코드 에디터(VS Code, IntelliJ 등)로 열어보면, Git이 충돌이 일어난 부분을 특수한 기호로 표시해 둔 것을 확인할 수 있습니다.
<<<<<<< HEAD
<button>일반 결제하기</button>
=======
<button>간편 간편결제 진행</button>
>>>>>>> feature-payment
기호의 의미는 다음과 같습니다.
<<<<<<< HEAD부터=======사이: 현재 내가 위치한 기준 브랜치(master)의 코드입니다.=======부터>>>>>>> feature-payment사이: 병합하려고 시도했던 대상 브랜치(feature-payment)의 코드입니다.
수동으로 코드 정리 후 커밋 마무리
충돌을 해결하는 방법은 간단합니다. 개발자가 직접 판단하여 위의 두 코드 중 하나를 선택하거나, 두 코드를 적절히 혼합하여 올바른 형태의 코드로 다시 작성하는 것입니다. 코드 작성이 끝났다면 <<<<<<<, =======, >>>>>>> 기호는 전부 지워주어야 합니다.
수정이 완료되었다면, 해당 파일을 다시 스테이징 영역에 추가하고 커밋을 완료하여 병합 상태를 종료합니다.
# 1. 수정한 파일을 스테이징 영역에 추가하여 충돌이 해결되었음을 Git에 알림
$ git add index.html
# 2. 병합 커밋 완료 (메시지는 자동으로 생성되므로 그대로 저장하고 종료해도 무방함)
$ git commit
병합을 취소하고 싶다면?
충돌이 너무 많이 발생하여 당장 해결하기 버겁거나 잘못된 브랜치를 병합했다면, 병합 과정 자체를 아예 취소하고 병합 전 상태로 되돌릴 수 있습니다.
명령어:git merge --abort
'CI.CD > GIT' 카테고리의 다른 글
| [GIT] Git 디버깅(Blame, Bisect)과 실무 브랜치 전략(Git Flow) (0) | 2026.08.07 |
|---|---|
| [GIT] 커밋 정밀 조작(Amend, Cherry-pick)과 최후의 복구 도구(Reflog) (0) | 2026.08.07 |
| [GIT] 깔끔한 히스토리를 위한 Rebase와 안전한 작업 되돌리기 (0) | 2026.08.07 |
| [GIT] 커밋 히스토리 관리 및 원격 저장소(GitHub) 협업 (0) | 2026.08.07 |
| [GIT] Git 시작하기와 로컬 워크플로우 완벽 가이드 (0) | 2026.08.07 |