GIT 브랜치 전략
브랜치 전략이 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용 하기 위한 work-flow
브랜치의 생성, 삭제, 병합 등의 git의 유연한 구조로 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다앙한 방식으로 소스를 관리하는 역할
브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론
GIT-FLOW 전략
- 기본적인 가지의 이름은 아래의 5가지로 구분
- feature > develop > release > hotfix > master
- 위 순서들은 왼쪽으로 갈수록 포괄적인 가지이며 master branch를 병합할 경우 그 왼쪽에 있는 hotfit 등 모든 가지들에 있는 커밋들도 병합하도록 구성
- 5가지 중, 항시 유지되는 메인 브랜치 master, develop 2가지와 merge 되면 사라지는 보조 브랜치 feature, release, hotfix 3가지로 구성
Git-flow 브랜치 구조
- master : 라이브 서버에 제품으로 출시되는 브랜치
- develop : 다음 출시 버전을 대비하여 개발하는 브랜치
- feature : 추가 기능 개발 브랜치, develop 브랜치에 들어간다.
- release : 다음 버전 출시를 준비하는 브랜치, develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다.
- hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치
메인 브랜치
메인 브랜치는 master 브랜치와 develop 브랜치 두 종류를 말한다.
master 브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며,
develop 브랜치는 다음에 배포할 것을 개발하는 브랜치
즉, develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.
보조 브랜치
보조 브랜치는 피처 브랜치(feature branch) 또는 토픽 브랜치(topic branch)를 말한다.
- 가지가 뻗어나오는 곳 : develop
- 뻗어나갔던 가지가 다시 합쳐지는 곳 : develop
- 이름 설정 : master, develop, release-, hotfix-를 제외하기만 하면 자유롭게 이름 설정이 가능하다.
- 새로운 기능을 추가할 때 주로 사용하는 가지이다.
master 브랜치에서 develop 브랜치를 만들었고,
develop 브랜치에서 다시 feature 브랜치를 나눠 작업을 하고 있는 것을 그림을 통해 알 수 있다.
develop 브랜치에는 기존에 잘 작동하는 개발코드가 담겨있으며, 보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 한다.
보조 브랜치는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merget하고 결과가 좋지 못하면 버리는 방향
보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin 에는 push하지 않는다.
릴리즈 브랜치
배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치
- 가지가 뻗어나오는 곳 : develop
- 뻗어나갔던 가지가 다시 합쳐지는 곳 : develop, master
- 이름 설정 : release-*
- 새로운 제품을 배포하고자 할 때 사용하는 가지
develop 브랜체으는 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release브랜치를 생성
배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그(ex, v0.1, v0.2)를 추가
핫픽스 브랜치
핫픽스 브랜치는 배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말한다.
- 가지가 뻗어나오는 곳 : master
- 뻗어나갔던 가지가 다시 합쳐지는 곳 : develop, master
- 이름 설정 : hotfix-*
- 제품에서 버그가 발생했을 경우에는 처리를 위해 이 가지로 해당 정보들을 모아준다.
버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속할 수 있다.
이때 만든 hotfit 브랜치에서의 변경 사항은 develop 브랜치에도 merge하여 문제가 되는 부분을 처리해줘야 한다.
Git flow 흐름
1. 신규 기능 개발
- 개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 feature 브랜치를 생성
- feature 브랜치에서 기능을 완성하면 develop 브랜치에 merge를 진행
2. 라이브 서버로 배포
- feature 브랜치들이 모두 develop 브랜치에 merge 되었다면 QA를 위해 release 브랜치를 생성
- release 브랜치를 통해 오류가 확인된다면 release 브랜치 내에서 수정을 진행
- QA와 테스트를 모두 통과했다면, 배포를 위해 release 브랜치를 master 브랜치 쪽으로 merge하며,
- 만일 release 브랜치 내부에서 오류 수정이 진행되었을 경우 동기화를 위해 develop 브랜치 쪽에도 merge를 진행
3. 배포 후 관리
- 만일 배포된 라이브 서버에서 버그가 발생된다면, hotfix 브랜치를 생성하여 버그 픽스를 진행
- 그리고 종료된 버그 픽스를 master와 develop 양 쪽에 merge하여 동기화
GITHUB-FLOW 전략
- Git flow가 좋은 방식이지만 GitHub에 적용하기에는 복잡하다는 Scott Chacon의 판단에 따라 만들어진 새로운 깃 관리 방식
- 자동화 개념이 들어가 있다 라는 큰 특징이 존재하며 만일 장도화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 된다
- Git flow에 비해 흐름이 단순해짐에 따라 그 규칙도 단순
- 기본적으로 master branch에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request 기능을 사용하도록 권장
GitHub-Flow 특징
- release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용
- GitHub 자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용
- 웹 서비스들에 배포의 개념이 없어지고 있는 추세이기 때문에 앞으로도 Git flow에 비해 사용하기에 더 수월
- hotfix와 가장 작은 기능을 구분하지 않는다.
Github-Flow 흐름
1. 브랜치 생성
Github-flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성
이때 체계적인 분류 없이 브랜치 하나에 의존하기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요
2. 개발 & 커밋 & 푸쉬
개발을 진행하면서 커밋을 남긴다.
이때도 브랜치와 같이 커밋 메시지에 의존해야 하기 때문에, 커밋 메시지를 최대한 상세하게 적어주는 것이 중요
3. PR(Pull Request) 생성
피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성
4. 리뷰 & 토의
Pull-Request가 master 브랜치 쪽에 합쳐진다면 곧장 라이브 서버에 배포되는 것과 다름 없으므로, 상세한 리뷰와 토의가 이루어져야 한다.
5. 테스트
리뷰와 토의가 끝났다면 해당 내용을 라이브 서버(혹은 테스트 환경)에 배포
배포 시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화
6. 최종 Merge
라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않았다면 그대로 master 브랜치에 푸시를 하고, 즉시 배포
github flow VS git flow
- 1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면
git-flow가 적합- 수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면
github-flow와 같은 간단한 work-flow가 적합하다.
참고문헌
