1. GIT 브랜치 전략
- 브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기위한 것
- 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론
2. GIT-FLOW 전략
- 브랜치의 이름은 아래 5가지로 구분한다
- feature > develop > release > hotfix > master
- 5개의 브랜치 중, 항시 유지되는 메인 브랜치는 master, develop 2가지이며 보조 브랜치 featrue, release, hotfix 는 merge 후에 삭제된다.
- GIT-FLOW 브랜치 구조
master 브랜치 : 라이브 서버에 출시되는 브랜치
develop 브랜치 : 다음 출시 버전을 개발하는 브랜치
feature 브랜치 : 추가 기능 개발 브랜치, develop 브랜치에 merge 된다.
release 브랜치 : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 테스트를 진행하고 최종 결과를 master, develop에 merge 한다.
hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치
2-1. 메인 브랜치
메인 브랜치는 master 브랜치와 develop 브랜치이다.
- master 브랜치는 배포 가능한 상태만을 관리하는 브랜치
- develop 브랜치는 다음에 배포 할것을 개발하는 브랜치
2-2. 보조 브랜치
보조 브랜치는 피처 브랜치(feature branch) 를 말한다.
- 브랜치가 나오는곳 : develop
- feature 브랜치가 다시 합쳐지는곳 : develop
master 브랜치에서 develop 브랜치를 만들었고,
develop 브랜치에서 다시 feature 브랜치를 나눠 작업을 진행한다.
develop 브랜치에는 기존에 잘 작동하는 개발코드가 담겨있으며,
보조 브랜치는 새로 변경될 개발코드를 분리하고 보존하는 역할을 한다.
즉, 보조 브랜치는 기능을 다 완성하고 develop 브랜치로 merge 후 삭제한다.
2-3. 릴리즈 브랜치
릴리즈 브랜치는 배포를 위한 최종적인 버그 수정등의 개발을 수행하는 브랜치
- 브랜치가 나오는곳 : develop
- 브랜치가 다시 합쳐지는곳 : develop, master
develop 브랜치에 버전에 포함되는 기능이 merge 되었다면 테스트를 위해 develop 브랜치에서 부터 release 브랜치를 생성한다.
배포 가능한 상태가 되면 master 브랜치로 병합시키고, release 브랜치에서 테스트를 진행하며 발생한 버그 수정 사항은 develop 브랜치에도 merge 해야한다.
2-4. 핫픽스 브랜치
핫픽스 브랜치는 배포한 버전에서 긴급하게 수정 할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말합니다.
- 브랜치가 나오는곳 : master
- 브랜치가 합쳐지는곳 : develop, master
- 버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 진행 할 수 있다.
이 때 만든 hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge 해야 한다.
- release 가지가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix 정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다.
- hotfix는 보통 급하게 버그를 고치기 위해 생성되는 가지이기 때문에 버그 해결 후 제거한다.
3. Git Flow 흐름
- 가장 많이 사용되는 브랜치는 master와 develop이며 정상적인 프로젝트를 진행하려면 모두 운용해야 한다.
- 나머지 feature, release, hitfix branch는 지우더라도 오류가 생기지 않기때문에 작업 후 삭제하고 필요 할 때만 다시 생성한다.
- 대부분은 작업은 develop에서 취합하며 테스트 등 모든 준비가 끝났을때 master로 병합을 진행하게 된다.
3-1. 신규 기능 개발
3-1-1. 개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 featrue 브랜치를 생성
3-1-2. feature 브랜치에서 기능을 완성하면 develop에 merge를 진행
3-2. 라이브 서버로 배포
3-2-1. feature 브랜치들이 모두 develop 브랜치에 merge 되었다면 테스트를 위해 release 브랜치를 생성
3-2-2. release 브랜치를 통해 오류가 확인된다면 release 브랜치 내에서 수정을 진행
3-2-3. 테스트를 모두 통과 했다면 배포를 위해 release브랜치를 master 브랜치로 merge
3-2-4. 만일 release 내부에서 오류 수정이 있었다면 동기화를 위해 develop 브랜치에도 merge
3-3. 배포 후 관리
3-3-1. 배포된 라이브서버(master)에서 버그가 발생된다면, hotfix 브랜치를 생성하여 버그 픽스를 진행
3-3-2. 수정된 버그 픽스를 master와 develop 브랜치에 merge하여 동기화
'Git & Github' 카테고리의 다른 글
| [Git & Github] Intellij에서 Git 기초 (0) | 2023.02.15 |
|---|---|
| [Git] IntelliJ에서 Git Commit Template 사용 (0) | 2023.02.15 |
| [GITHUB] 깃허브 브랜치 전략 - GITHUB FLOW (0) | 2023.02.09 |
댓글