Git Branch 종류와 사용법
Branch의 종류와 사용법
1. Git Branches
브랜치 생성, 관리, 삭제
git branch 명령은 브랜치의 생성, 관리, 삭제 전과정에 사용되는 명령어입니다.
(1) 브랜치 생성 은 다음과 같은 형태입니다.
git branch [브랜치명]
ex>
git branch test1
(2) 생성한 브랜치 확인
git branch
* master
test1
master와 생성된 브랜치들의 표시됩니다.
*는 현재 작업 중인 브랜치를 뜻함.
(3) 브랜치 이름 변경
-m (또는 --move) 옵션을 사용하면 브랜치 이름을 변경할 수 있습니다.
git branch -m [기존 브랜치명] [변경할 브랜치명]
test2 브랜치를 test3으로 이름변경 해보자. 다음과 같이 입력하면 됩니다.
git branch -m test2 test3
$ git branch -m test1 test
$ git branch
* master
test
(4) 브랜치를 삭제하려면 -d 옵션을 사용합니다.
git branch -d [브랜치명]
(5) 브랜치 전환
브랜치를 전환하기 위해 git checkout 명령을 사용합니다.
git checkout [브랜치명]
2. Git Branches 종류
Git Workflow는 수명이 항상 유지되는 메인 브랜치(master, develop)와
일정 기간 동안만 유지되는 보조 브랜치(feature, release, hofix) 총 5개의 브랜치를 사용합니다.
<Git Workflow>
메인 브랜치 (Main Branch)
< main branch>
main 브랜치는 배포 가능한 상태만을 관리하며, 커밋할 때는 태그를 사용해 배포(Release) 번호를 기록합니다. 위의 Workflow를 이용한 협업에서 작업한 결과물을 서브 브랜치가 아닌 main에 바로 올려 버리면 안됩니다.
< develop branch >
develop 브랜치는 기능 개발을 위한 feature 브랜치들을 병합하기 위해 사용합니다. 평소에는 이 브랜치를 기반으로 개발을 진행하며, 모든 기능이 추가되고 버그가 수정되어 배포에 문제가 없을 때, master 브랜치에 병합하게 됩니다.
develop 브랜치 생성
$ git branch develop
저장소에 올림
$ git push -u origin develop
보조 브랜치 (Supporting Branch)
< feature branch >
feature 브랜치는 새로운 기능을 개발하거나 버그를 수정할 필요가 있을 때마다 develop 브랜치로부터 분기합니다.
이 브랜치에서의 작업은 보통 공유할 필요가 없고 그 부분을 맡은 사람만 작업을 하게 되기 때문에 로컬 저장소에서 관리하게 됩니다.
개발이 완료되면 develop 브랜치에 병합하여 다른 사람들과 공유하고, 해당 브랜치는 삭제합니다.
feature/login 브랜치 생성 후 전환
$ git checkout -b feature/login develop
작업 수행 후 develop 브랜치로 이동 후 병합
$ git checkout develop
$ git merge --no-ff feature/login
구현이 끝난 브랜치 삭제 후 저장소에 올림
$ git branch -d feature/login
$ git push origin develop
git merge 명령의 --no-ff 옵션은 합치고자 하는 브랜치(feature/login)에 존재하는 모든 커밋 이력을 하나로 합쳐 새로운 커밋을 생성한 후 병합할 수 있도록 합니다. 하나의 기능을 구현할 때 너무 많은 커밋을 남기게 되면, 부모 브랜치와 병합하면서 불필요한 이력이 많아지기 때문에 정리하는 것입니다.
< release branch >
release 브랜치는 출시할 버전을 준비하는 브랜치입니다.
배포만을 위한 브랜치를 사용함으로써 배포를 준비 중인 팀은 이곳에만 집중하고, 다른 팀은 다음 배포를 위한 기능 개발을 이어갈 수 있습니다.
직접적으로 관련된 내용을 제외하고는 새로운 기능을 병합하지 않고 버그 수정과 문서 작업 정도를 수행합니다.
모든 배포 준비가 완료되면 master 브랜치에 병합하며
변경 사항이 있을 수 있기에 develop 브랜치에도 병합 후 삭제해 줍니다.
release 브랜치 생성 후 전환
$ git checkout -b release-1.1 develop
배포 작업 수행 후 master 브랜치로 이동 후 병합
$ git checkout master
$ git merge --no-ff release-1.1
병합한 커밋에 Release 버전에 대한 태그 부여
$ git tag -a 1.1
develop 브랜치에도 병합 후 삭제
$ git checkout develop
$ git merge --no-ff release-1.1
$ git branch -d release-1.1
< hotfix branch >
hotfix 브랜치는 출시 버전에서 발생한 버그를 빠르게 수정할 필요가 있을 때 master에서 분기하는 브랜치입니다.
문제가 되는 부분만을 빠르게 수정하여, 바로바로 동작할 수 있도록 해야 합니다.
문제를 해결했으면 master 브랜치에 병합하며 새로운 버전 이름으로 태그를 붙여 주면 됩니다.
hotfix 브랜치의 변경 사항은 develop 브랜치에도 병합해야 하고, 그 이후에는 다른 보조 브랜치와 동일하게 제거하면 됩니다.
release(1.1)에 대한 hotfix를 master에서 분기
$ git checkout -b hotfix-1.1.1 master
문제 해결 후 master 브랜치로 이동 후 병합
$ git checkout master
$ git merge --no-ff hotfix-1.1.1
병합한 커밋에 새로운 버전에 대한 태그 부여
$ git tag -a 1.1.1
develop 브랜치에도 병합 후 삭제
$ git checkout develop
$ git merge --no-ff hotfix-1.1.1
$ git branch -d hotfix-1.1.1
브랜치 이름 규칙
< feature >
- 추천하는 형식은 "feature/기능"의 형태이며, 예를 들어 "feature/login" 등이 있습니다.
- 만약 Issue tracker id를 사용한다 하면, "feature/{issue-id}-{name}"으로 만들 수 있습니다.
< release >
- "release-버전"의 형식으로 사용하는 것을 추천합니다.
< hotfix >
- "hotfix-버전"의 형식으로 사용하는 것을 추천합니다.
참고
A successful Git brancing model