GIT 브랜치 전략이란?
브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow 이다.
브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용하여, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 한다.
즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말한다.
왜 사용해야 하는데?
브랜치 전략이 없다면, 즉 규칙이 없다면 서로에게 혼란을 야기할 수 있다.
예를들어,
어떤 브랜치가 최신 브랜치지?
어떤 브랜치를 끌어와서 개발을 시작해야 하지?
어디에 Push를 보내야 하지?
핫픽스를 해야하는데 어떤 브랜치를 기준으로 수정해야할까?
배포 버전은 어떤 걸 골라야하지?
등등 규모가 커지면 커질수록 생길 수 있는 여러가지 혼란들을 미리 방지할 수 있다.
그래서 어떤 전략들이 있는데?
가장 대표적으로 사용하는 2가지 전략있는데 이것들에 대해 알아보자.
git-flow 전략
github-flow 전략
Git-Flow 전략
gitflow에는 5가지 브랜치가 존재하는데,
master : 기준이 되는 브랜치로 라이브 서버에 제품으로 출시되는 브랜치이다.
develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge 한다.
feature : 추가 기능 개발 브랜치. 기능 개발이 완료되면 develop 브랜치에 Merge 한다.
release : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다.
hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치.
메인 브랜치
메인 브랜치는 master 브랜치와 develop 브랜치 두 종류를 말한다.
master 브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며,
develop브랜치는 다음에 배포할 것을 개발하는 브랜치이다.
즉 develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.
보조 브랜치
보조 브랜치는 피처 브랜치(feature branch) 또는 토픽 브랜치(topic branch)를 말한다.
새로운 기능을 추가할 때 주로 사용하는 브랜치 이다.
master 브랜치 -> develop 브랜치 -> feature 브랜치로 나눠 작업을 하고 있는 것을 그림을 통해 알 수 있다.
보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 한다.
보조 브랜치는 기능을 다 완성한 후 develop 브랜치로 merge 하거나 결과가 좋지 않다면 버리는 방향을 취한다.
보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin에는 push하지 않는다.
릴리즈 브랜치(release branch)
릴리즈 브랜치는 배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말한다.
새로운 제품을 배포하고자 할 때 사용하는 브랜치 이다.
develop 브랜치에 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성한다.
배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그(ex, v1.0, v0.2)를 추가한다.
핫픽스 브랜치(hotfix branch)
핫픽스 브랜치는 배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말한다.
제품에서 버그가 발생했을 경우에는 처리를 위해 이 브랜치로 해당 정보들을 모아온다. 버그에 대한 수정이 완료된 후에는 develop, master에 곧장 반영해주며 tag를 통해 관련 정보를 기록해둔다.
버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속할 수 있다.
release 가지가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다.
gitflow 과정을 정리하자면
- master 브랜치에서 develop 브랜치를 분기합니다.
- 개발자들은 develop 브랜치에 자유롭게 커밋을 합니다.
- 기능 구현이 있는 경우 develop 브랜치에서 feature-* 브랜치를 분기합니다.
- 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치를 분기합니다.
- 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영합니다.
- 테스트가 완료되면 release 브랜치를 master와 develop에 merge합니다.
GitHub-Flow 전략
GitHub-Flow 는 Git-flow가 Github에서 사용하기에는 복잡하다고 나온 브랜치 전략이다.
- 수시로 배포가 일어나며, CI와 배포가 자동화되어있는 프로젝트에 유용하다.
- Git flow에 비해 흐름이 단순해짐에 따라 그 규칙도 단순하다.
- 기본적으로 master branch에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request기능을 사용하도록 권장한다.
- hotfix 브랜치나 feature 브랜치를 구분하지 않는다. 다만 우선순위가 다를 뿐이다.
1. 브랜치 생성
Github-flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작된다.
단, 이때 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요하다.
- master 브랜치는 항상 최신 상태여야 한다.
- 새로운 브랜치는 항상 master 브랜치에서 만든다.
- 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성한다.
2. 개발 & 커밋 & 푸쉬
브랜치와 같이 커밋 메세지에 의존해야 하기 때문에, 커밋 메세지를 최대한 상세하게 적어주는 것이 중요하다.
- 커밋메시지를 명확하게 작성하자.
- 잊지말고 원격지 브랜치로 수시로 push 하자.
- 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다.
- 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다.
3. PR(Pull Request) 생성
피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다.
- pull request는 코드 리뷰를 도와주는 시스템으로 자신의 코드를 공유하고, 리뷰받는다.
- merge 준비가 완료되었다면 master 브랜치로 반영을 요구한다.
4. 리뷰 & 토의
Pull-Request가 master 브랜치 쪽에 합쳐진다면 곧장 라이브 서버에 배포되는 것과 다름 없으므로, 상세한 리뷰와 토의가 이루어져야 한다.
5. 테스트
리뷰와 토의가 끝났다면 해당 내용을 라이브 서버(혹은 테스트 환경)에 배포해본다.
배포시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화 시킨다.
6. 최종 Merge
라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않았다면 그대로 master 브랜치에 푸시를 하고, 대부분의 Github-flow 에선 master 브랜치를 최신 브랜치라고 가정하기 때문에 배포 자동화 도구를 이용해서 Merge 즉시 배포를 시킨다.
- master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다. (CI / CD)
Reference
