Git Branch
는 Git에서 매우 중요한 개념 중 하나입니다.
이번 포스트에서는 Git Branch란 무엇인지, Git Branch를 활용하여 어떻게 코드를 관리할 수 있는지, 그리고 Git Branch를 활용한 협업 방법 등에 대해 살펴보겠습니다.
- "모든 버전 관리 시스템은 브랜치를 지원한다. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치다."
↳ 출처 : Git 브랜치 - 브랜치란 무엇인가
Git Branch는 Git에서 코드를 분기하여 관리하는 개념입니다.
Git에서는 기본적으로 main
혹은 master
라는 하나의 브랜치를 가지고 있으며, 이 브랜치에서 새로운 브랜치를 만들어 작업을 진행합니다.
새로운 브랜치를 만들면, 기존 브랜치와 독립적으로 코드를 변경할 수 있어 기능 개발, 버그 수정, 실험적 시도 등을 안전하게 수행할 수 있습니다.
$ git branch
*
표시로 나타납니다.예시:
$ git branch -a
예시:
$ git branch -a
* main
remotes/origin/HEAD -> origin/main
remotes/origin/main
해석:
* main
→ 지금 당신은 로컬의 main 브랜치에서 작업 중입니다.origin/main
은 원격 저장소(origin) 에 있는 main
브랜치입니다.remotes/origin/HEAD -> origin/main
origin
이라는 원격 저장소의 기본 브랜치는 main
임을 의미합니다.HEAD
는 그 기본 브랜치를 가리키는 포인터입니다.Q. 지금 사용하는 브랜치
main
이origin/main
이랑 같은 거야?
- 👉 완전히 같지는 않아요.
main
: 내 컴퓨터(Local) 에 있는 브랜치origin/main
: 원격 저장소(Remote) 에 있는 브랜치
→ 즉, 같은 이름이지만 서로 다른 공간에 있습니다.
→ 그리고, 우리는 이들을 서로 동기화(push/pull) 하면서 관리하는 것입니다.
보통은 이런 식으로 관리합니다 :
# 원격의 최신 내용을 내 로컬 main 브랜치에 반영
$ git pull origin main
# 로컬의 변경 내용을 원격 main에 반영
$ git push origin main
Q. 난 의심이 많아. 로컬 브랜치
main
이 원격 브랜치origin/main
과 정말 연결되어 있는지(매칭되는지) 확인하고 싶어.
- 👉
git status
로 확인이 가능합니다.
입력:
$ git status
출력:
On branch main
Your branch is up to date with 'origin/main'.
$ git branch <새 브랜치 이름>
예:
$ git branch feature/login
혹은 생성과 동시에 전환하려면:
$ git checkout -b feature/login
$ git branch -m <새 브랜치 이름>
현재 브랜치에서 변경하는 경우:
$ git branch -m feature/login feature/auth
$ git branch -d <삭제할 브랜치 이름>
강제 삭제 (병합 안 된 경우도 포함):
$ git branch -D <삭제할 브랜치 이름>
$ git checkout <전환할 브랜치 이름>
또는 Git 2.23 이후에는 switch
명령도 사용 가능:
$ git switch feature/login
# 1. 기준 브랜치(main 또는 dev) 최신화
$ git checkout main
$ git pull origin main
# 2. 새로운 기능 브랜치 생성 및 전환
$ git checkout -b feat/user-profile
# 3. 작업 후 커밋
$ git add .
$ git commit -m "✨ feat: 사용자 프로필 페이지 생성"
# 4. 원격 저장소에 새 브랜치 푸시
$ git push -u origin feat/user-profile
# 5. PR 생성 → 리뷰 → Merge → 브랜치 삭제
# 1. 저장소 clone (처음 받는 경우)
$ git clone https://github.com/your-org/your-repo.git
$ cd your-repo
# 2. 원격 브랜치 목록 확인
$ git branch -r
# 3. 작업할 브랜치 checkout (로컬 브랜치 생성 + 자동 트래킹)
$ git checkout feat/user-profile
# 또는 명시적으로
$ git checkout -b feat/user-profile origin/feat/user-profile
# 4. 작업 시작
$ git pull # 혹시 최신 상태가 아닐 경우
$ git status
$ git add .
$ git commit -m "♻️ fix: 프로필 UI 수정"
# 5. 원격 저장소로 푸시
$ git push # 이미 tracking 중이면 브랜치명 생략 가능
Git Branch 전략은 협업 시 브랜치 명명 규칙, 생성/병합 흐름을 명확히 하기 위한 전략적 선택입니다. 아래는 대표적인 3가지 전략입니다.
구성:
main
: 실제 운영 중인 코드 (배포용)develop
: 개발 통합 브랜치feature/기능
: 기능 개발 브랜치release/버전
: 출시 준비 브랜치hotfix/이슈
: 운영 이슈 긴급 수정# 예시: feature 브랜치 생성
$ git checkout -b feature/search-filter develop
main
에서 직접 브랜치를 파서 작업 후 Pull RequestCI/CD
가 자동으로 동작하며 배포 가능main
, production
, feature
, bugfix
, release
브랜치를 혼합적으로 운용$ git checkout -b feature/payment
$ git push origin feature/payment
main
또는 develop
브랜치로 병합하기 전 리뷰 필수브랜치 타입 | 명명 규칙 | 용도 |
---|---|---|
기능 추가 | feature/<기능명> | 새 기능 개발 |
버그 수정 | bugfix/<이슈명> | 발견된 버그 수정 |
긴급 패치 | hotfix/<이슈명> | 운영 중 긴급 수정 |
배포 준비 | release/<버전> | QA 및 배포 전 최종 검수용 브랜치 |
실험/개인 테스트 | experiment/<주제> | 실험적 코드 테스트 |
Auto-merging app.py
CONFLICT (content): Merge conflict in app.py
해결 방법:
app.py
파일을 열어 <<<<<<<
, =======
, >>>>>>>
로 표시된 부분을 확인$ git add app.py
$ git commit -m "Resolve merge conflict in app.py"
rebase
vs merge
비교Git에서 충돌(conflict) 은 두 브랜치에서 동일한 파일의 같은 라인을 수정하고 병합할 때 발생합니다. Git은 어떤 변경을 적용해야 할지 자동으로 결정할 수 없기 때문에, 사용자가 수동으로 해결해야 합니다.
# main 브랜치에서 새로운 파일 생성
$ git checkout -b main
$ echo "console.log('Hello from main');" > app.js
$ git add app.js
$ git commit -m "Main: Add greeting message"
# feature 브랜치 생성 및 수정
$ git checkout -b feature
$ echo "console.log('Hello from feature');" > app.js
$ git commit -am "Feature: Update greeting message"
# main 브랜치에서 다른 내용으로 수정
$ git checkout main
$ echo "console.log('Hello from MAIN branch');" > app.js
$ git commit -am "Main: Change greeting message"
이제 feature
브랜치를 main
에 병합하려고 하면 충돌이 발생합니다.
# feature 브랜치에서 main 병합 시도
$ git checkout feature
$ git merge main
출력:
Auto-merging app.js
CONFLICT (content): Merge conflict in app.js
Automatic merge failed; fix conflicts and then commit the result.
app.js
파일을 열어보면 아래와 같은 충돌 마커가 표시됩니다.
<<<<<<< HEAD
console.log('Hello from feature');
=======
console.log('Hello from MAIN branch');
>>>>>>> main
해결 방법:
console.log('Hello from BOTH branches');
$ git add app.js
$ git commit -m "Resolve conflict in app.js"
이제 충돌이 해결되었습니다.
항목 | merge | rebase |
---|---|---|
목적 | 두 브랜치를 통합 | 브랜치 기반을 최신 커밋으로 변경 |
커밋 이력 | 브랜치 병합 히스토리 유지 (merge commit ) | 커밋 히스토리를 깔끔하게 재작성 |
사용 상황 | 협업 기록을 명확히 남기고 싶을 때 | 개인 브랜치 정리, 깔끔한 히스토리 관리 시 |
충돌 발생 시점 | 병합 시점 | rebase 과정 중 각 커밋마다 충돌 가능성 있음 |
명령어 예시 | $ git merge main | $ git rebase main |
# feature 브랜치에서 main 변경 사항을 rebase
$ git checkout feature
$ git rebase main
중간에 충돌이 발생하면 동일하게 수동 해결 후:
$ git add app.js
$ git rebase --continue
전체 rebase 중단은:
$ git rebase --abort
merge
는 병합 이력을 명확히 보여주는 반면,rebase
는 히스토리를 깔끔하게 정리하는 데 유리합니다.merge
를, 개인 브랜치 정리에는 rebase
를 활용하는 것이 권장됩니다.