이번에는 Git 브랜치 전략 중 하나인 Git-Flow를 알아보려고 합니다.
Git 브랜치 전략이란?
말 그대로 깃 브랜치들에 전략(=규칙)을 부여하는 것임.
각 브랜치로부터 어떤 브랜치들을 생성할건지, 각 브랜치가 어디서 분기되어서 생성될건지, 각 브랜치는 다시 어떤 브랜치로 병합되어야 하는지 등등 각 브랜치 별 규칙을 정하는 것을 말한다.
좀 더 정리하자면, Git 브랜치 전략 = 브랜치 네이밍 컨벤션 정하기 + 각 브랜치 별 전략(각 브랜치에서 어떤 종류의 브랜치가 나오고 들어올지 등) 정하기
Git 브랜치 전략의 필요성
왜 이런 브랜치 전략이 필요할까? 이런 브랜치 전략이 없다면, 팀원들 간 저장소 내에서 브랜치를 관리하는데 어려움을 겪을 것이다.
때문에 각 브랜치에서는 어떤 이름의 브랜치를 만들것인지, 그리고 이렇게 만들어진 브랜치는 다시 언제 어디로 다시 합쳐지게 될 것인지를 명확히 정해야할 필요가 있다.
GitHub-Flow vs Git-Flow
대표적으로 두 가지의 깃 브랜치 전략이 있다. 이 두 가지를 한 번 알아보도록 하자.
Git Flow
아래는 Git Flow의 설명을 담은 그림임.
핵심 브랜치들
- master: 운영환경에 배포되는 코드가 담긴 브랜치
- develop: 아직 배포 되기 전 코드를 모으는 브랜치, 즉 다음 버전에 대한 코드들이 담긴 브랜치다. master로 머지될 예정인 브랜치다.
지원 브랜치들
- feature: 새로운 기능을 개발하는 브랜치, develop 브랜치에서 생성되며 다시 develop 브랜치로 머지된다.
- release: 릴리즈 브랜치는 이번 배포에 대한 메타 데이터(버전명, 빌드 날짜 등)들을 담은 커밋과 QA과정에서 생긴 커밋(버그 수정 등)을 담아서 develop브랜치나 master 브랜치에 다시 머지시키는 용도의 브랜치다.
릴리즈 브랜치는 develop브랜치에서 파생되어 나온다. 브랜치 이름은 보통 release-1.2와 같이 release-x.y.. 으로 짓는다. 이 브랜치를 대상으로 QA가 진행된다. QA과정에서 발생한 버그는 이 브랜치에서 수정한다. QA를 통과하게 되면 그때 master와 develop으로 머지시키는 것임. - hotfix: 배포된 코드를 빠르게 수정해야할 때, 즉 master 브랜치를 수정하기 위해 사용한다. master 브랜치에서 파생되며 수정 후에는 master와 develop에 모두 머지되어야 한다.
Git Flow는 릴리즈 브랜치를 둠으로써 버전 상태 관리에 힘쓰고 있다는 것이 한 눈에 보인다. 즉, 버전을 배포 환경과 동기화 시키는 것을 중요시 여기는 앱 개발에서는 사용할만하지만, 버전이 항상 최신상태로 유지되는 웹에서는 적절하지 않다는 것을 말한다. 그리고 이것의 대안으로 GitHub Flow를 제안하고 있다.
GitHub Flow
Git Flow가 깃헙에서 사용하기 복잡하다는 이유로 등장했다고 함. 또한, Git Flow를 제안한 사람도 앱 같은 버전 동기화가 중요한 프로젝트가 아니라면 GitHub Flow같은 간단한 전략을 사용하라고 말하고 있다.
우선, GitHub Flows는 브랜치 종료를 단 두 종류로 밖에 구분하지 않는 간단한 깃 브랜칭 전략이라고 한다.
- master: 언제든 배포 가능한 상태로 유지되는 브랜치. 이 브랜치에 머지되기 전에는 충분한 검증(테스트 등)이 필요하다.
- 기타 브랜치들: master 브랜치 이외는 모두 자유 형식이다. Git Flow에서 봤던 feature나 hotfix 같은 종류의 브랜치를 별도로 정의하지 않으며, 그냥 브랜치의 이름을 팀 내에서 알아서 정하고 사용하면 된다.
GitHub Flow의 장점은 단순하기 때문에 복잡하지 않고, 자동 배포에 대해서도 쉽게 적용 가능하다는 것이 있다.
결론
사실 깃 브랜칭 전략이라는 것 자체가 디자인 패턴과도 같다고 생각한다. 우리의 프로젝트 상황에 따라 얼마든지 우리가 원하는 형태로 바꿔도 된다고 생각한다.
번외편) GitLab Flow
GitHub Flow가 너무 간단해서 배포, 릴리즈 등의 복잡한 이슈를 보완하기 위해 나온 전략이라고 함.
GitHub Flow의 master 브랜치에서 바로 배포되는 그 과정의 중간에 PRE-PRODUCTION 단계의 브랜치를 하나 놓는 것.
- master: 전체적인 테스트 진행으로 기능이 보장되었다면 바로 Production으로 머지해도 되고, 잠시 다른 단계가 더 필요하다면 pre-production 브랜치에 머지하면 된다.
- production: 테스트가 끝난 기능에 대해 배포하기 위한 브랜치
- pre-production: 변경 사항을 바로 production에 배포하지 않고, 테스트 서버 등으로 한 번 배포하고 검증의 시간을 가질 수 있게 해주는 브랜치.
참고
https://techblog.woowahan.com/2553/
https://ksh-coding.tistory.com/109
https://brownbears.tistory.com/605
