Git flow란 무엇인가? Github flow 비교 및 브랜치 활용 전략
업데이트:
Git flow, 그리고 Github flow
개요
Git flow란 무엇인가?
Git flow는 Git에서 소스코드를 관리하고 활용하는데에 적용가능한 브랜치 관리 전략 중 하나이다.
초기 제안된 workflow 디자인을 기반으로 만들어진 전략이며, 현재 많은 기업과 개발단위 팀에서 활용중이다.
당신이 처음 Git을 접했을 때에는 master 브랜치 하나로만 사용했을 것이다.
이후 버전 관리를 위해 develop 개발 브랜치를 생성하여 개발내용을 반영하고 master 브랜치는 최신 형상을 관리하는 방향으로 사용하는게 일반적이다.
이후로는 협업을 위해 각 개발자 브랜치나, 이슈별 브랜치 등 각기 다른 flow를 작성하여 사용중일 것이다.
우리는 이러한 방식을 github flow라고 부른다.
하지만 개발에 참여하는 인원이 증가하거나 프로젝트 규모와 기간이 증가될 때에는 위의 개발 프로세스로는 한계를 겪을 경우가 많을 것이다.
그렇기 때문에 대중적인 모델인 git flow 디자인이 제시된다.
Github flow
Github flow와 Git flow는 명칭만 보아선 같은듯 하지만 다른 모델이다.
Github flow는 github에서 제시하고 권장하는 모델이다. 또한 페이지에 기본적으로 구성되어있다.
개요에서 잠깐 설명한 관리 방식이 Github flow 디자인이다.
간단하게 master branch로 최신 형상을 관리하고, 하위 브랜치들(feature branch)로 작업을 처리하는 관리방식으로 생각하면 된다.
우리가 처음 Github에서 사용한 브랜치 관리 방식이 지금껏 쭉 사용되고 있는 것이다.
그 만큼 비교적 접근하기 쉬운 간단하고 강력한 디자인이다.
- 장점
- 깔끔하고 간단한 협력 규칙
- 지속적인 통합과 개발의 편리함
- 빠른 피드백과 이슈 발행 및 변화를 독려
- feature 개발 이후 dvelop, release까지 전달할 필요가 없음
- 단점
- Git-Flow에 비해 체계적이지 않음. 자유분방한 코드 관리
- 짧은 주기가 아닌 큰 주기의 release의 환경에는 맞지 않음
- 운영과 개발 브랜치 모두를 감당하는 master 브랜치는 코드가 지저분 할 수 있음
- release 준비와 버그 수정이 모두 master 브랜치에 있으므로 특별한 주의가 더 필요함
Git flow
위에서 설명한 Github flow는 빠르고 간단하고 즉각 피드백을 반영할 수 있는 장점이 있다.
하지만 규모가 큰 프로젝트나 기간이 길고 팀의 규모도 클 경우, 해당 모델은 오히려 복잡하고 관리의 어려움을 유발할 수 있다.
따라서 더욱 체계적인 관리 모델의 채택 필요성을 느낀다면 Git flow가 그 대안으로 제시된다.
Git flow는 5가지 브랜치 전략을 가지고 있다.
- Master : 제품으로 출시될 수 있는 브랜치
- Develop : 다음 출시 버전을 개발하는 브랜치
- Feature : 기능을 개발하는 브랜치
- Release : 이전 출시 버전을 준비하는 브랜치
- Hostfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
위 타임라인을 하나씩 보면 체계적으로 관리가 되고있음을 확인할 수 있다.
처음 master 브랜치와 develop 브랜치가 생성되고 여러 브랜치에서 작업이 이루어진다. 브랜치 별로 특징이 있기 때문에 해당 특징에 대한 개발 프로세스만 진행되면 된다는 장점이 있다.
개발 프로세스를 나열하면 다음과 같다.
- master, develop 브랜치 생성
- develop 브랜치/보통 개발, feature 브랜치/기능 개발
- feature 브랜치 개발완료시 develop 브랜치로 PR
- develop 브랜치 확인 후 merge, feature 브랜치 삭제
- develop 브랜치에서 개발 완료 후 release 브랜치 생성 후 QA진행
- release 브랜치에서 이슈 발생시 release 내에서 반영
- release 브랜치 검증 완료시 master와 develop으로 PR 후 merge
- master 브랜치에 버전 태그 추가
이런 git flow에도 장점만 있는 것은 아니다. 이전에 살펴본 github flow와 비교했을때 상대적으로 딱딱하고 복잡한 것이 단점이다.
- 장점
- 브랜치별로 책임을 명확히 하는 규칙성
- 매우 디테일하게 버전 정보 제공
- master에 있는 코드는 매우 깔끔한 상태 유지(테스트되고 최종 수정된 것만 반영되기 때문)
- 브랜치별로 역할이 있으므로 문제가 있더라도 문제 발생시 각 브랜치를 대기 시킬 필요가 없음(freeze)
- 단점
- 많은 브랜치 때문에 생기는 복잡한 규칙
- release 로 인한 많은 동기화 작업
- 애자일의 반복적인 접근법과 Git-Flow의 엄격하고 구체적인 규칙과 충돌
정리
이렇듯 github flow와 git flow는 서로 장단점이 존재한다.
굳이 여러 유명 기업에서 git flow를 채택하고 있다고 해서 개발 프로세스를 변경할 필요도 없고, 반대로 잘 쓰고있는 git flow에서 github flow로 넘어갈 필요도 없다.
또한 여기서 소개한 github flow나 git flow 외에도 gitlab flow, trunk-based development 등 여러가지 전략들이 존재하고 각 기업들마다 독자적인 개발 프로세스 또한 많이 존재할 것이다.
소속된 개발팀의 프로세스와 팀내 개발 구성원들의 규모나 성향, 그리고 평균 프로젝트 기간과 규모 등을 종합하여 프로젝트에 적합한지를 검토하여 효율적인 개발 프로세스를 채택하여 사용하면 된다.
댓글남기기