깃 브랜치 관리와 전략은 협업의 효율성을 결정짓는 중요한 요소이다.
깃 브랜치를 잘 이해하고 적절한 규칙과 전략을 세우면 프로젝트의 흐름을 체계적으로 관리할 수 있다.
오늘은 깃 브랜치 이름 규칙부터 병합 전략까지,
깃 브랜치를 효과적으로 사용하는 방법을 알기 쉽게 정리 해보겠다.
예시)
메인 브랜치: v1.2.0
기능 개발: feature/login, feature/select-product, ...
: 새로운 기능을 개발할 때는 feature/ 접두어를 사용하여 명확하게 구분한다.
출시 준비: release-1.3, release-1.4, ...
: 배포 전에 테스트와 안정화 작업을 진행하는 브랜치로, release- 접두어를 붙인다.
긴급 수정: hotfix-1.2.1
: 배포 이후 발견된 치명적인 버그를 수정할 때는 hotfix- 접두어를 사용한다.
명명 규칙을 지키면 브랜치 이름만 보고도 용도를 쉽게 파악할 수 있어 협업 시 혼선을 줄일 수 있다.

이게 지금 현재 내 깃 히스토리이다.
실습을 진행하면서 여러 단계를 먼저 해봤지만 아래 과정을 따라오면
정상적으로 위 같은 화면처럼 보이게 된다.
- 깃허브 레포지토리에 접속하여
Branches탭을 클릭한다.New Branch버튼을 클릭하고 새로운 브랜치 이름을 입력한다.- 기본 브랜치에서 파생되도록 설정한 후,
Create Branch를 클릭한다.
또는
터미널에서
git branch <사용할 브랜치명>을 입력한다.

다음 명령어를 통해 로컬 브랜치를 원격 브랜치로 push 할 수 있다:
git push <깃허브저장소별칭> <깃브랜치명>
예를 들어, 원격 저장소가 origin이고
브랜치 이름이 feature/login이라면 다음과 같이 실행한다:
git push origin feature/login

이 과정을 통해 깃허브에서도 동일한 브랜치를 확인할 수 있다.
전략은 다양하지만, 대표적인 두 가지 브랜치 병합 전략을 소개한다.
A 브랜치에서 B 브랜치를 생성한 시점부터,
A 브랜치에는 추가 구현이 없고,
B 브랜치에서만 추가 구현을 한 뒤
B 브랜치와 A 브랜치를 병합하면, A 브랜치에 B 브랜치가 그대로 붙는다.
이 전략은 간단하고 이력이 깔끔하게 남지만,
병합 이력이 단조로워져 대규모 프로젝트에서는 사용이 제한될 수 있다.
일반적으로 가장 많이 사용하는 전략이다.
A 브랜치에서 B 브랜치를 생성한 시점부터,
A 브랜치에서도 추가 구현을 하고,
B 브랜치에서도 추가 구현을 한다.
병합 시, A 브랜치와 B 브랜치를 서로 비교하여 바뀐 부분을 정리하고 병합한다.
이 전략은 충돌 관리가 필요하지만,
이력을 명확히 추적할 수 있어 협업에 유리하다.
브랜치 전략은 팀의 협업 방식과 프로젝트 특성에 따라 유연하게 선택하면 된다.
브랜치를 생성하는 이유는 "협업"을 위한 것.
깃허브에서는 주로 브랜치를 병합(추가 브랜치 -> 메인 브랜치)한다.
주요 과정
Main 브랜치 보호:
Pull Request 생성:
추가 브랜치를 메인 브랜치에 병합하기 위해 PR을 생성.
깃허브가 병합 과정에서 충돌 여부를 자동으로 확인.
PR 메시지 작성:
병합 수행:
병합된 브랜치 삭제:
병합 과정에서 충돌이 발생하면 깃허브 또는 로컬에서 수동으로 해결해야 한다.
변경 파일을 확인하고 필요한 부분을 수정한 뒤, 병합을 다시 시도한다.
병합된 깃허브 상태를 로컬 깃과 동기화하려면 아래와 같이 하면 된다 :
git fetch -p

git checkout main
git pull origin main
git branch -d <삭제할 브랜치>
예를 들면 feature/login 브랜치를 삭제하려면:
git branch -d feature/login



로컬과 원격 브랜치 상태를 정리하면 깔끔한 협업 환경을 유지할 수 있다.
오늘은 브랜치에 대해서 알아보았다.
협업을 해본 경험이 적지만 이런 방식으로 코드 공유가 된다는 것을
알게 된 시간이여서 너무 유익했다.
지금 하고 있는 토이 프로젝트를
오늘 배운 내용을 적용해보겠다.