브랜치 전략이란?

브랜치 관리 방법입니다.
브랜치 전략에 따라 업무 프로세스가 달라집니다. 실제로 업무 프로세스에서 많은 차이를 느꼈습니다. 정말 중요한 장치가 될지, 개발속도를 늦추는 불필요한 단계가 될지 환경에 맞게 잘 사용해야합니다.
다양한 회사에서 채택하는 대표적인 방식 : GitFlow, GitHubFlow, GitLabFlow

■ GitFlow

특징

2010년, 온라인에서 nvie라는 닉네임을 사용하는 한 개발자가 고안해낸 방법입니다.
규모가 큰 기업에서 표준으로 주로 사용하는 브랜치 전략입니다. - 예) 우아한 형제들(안드로이드)
5개의 브랜치 운영
브랜치 종류
- 메인 브랜치 : 항상 유지
  - master - 제품 코드가 존재
  - develop - master 브랜치에서 분기 - 개발자들이 개발을 하는 브랜치
- 보조 브랜치 : 사용을 마치면 삭제
  - feature - 기능구현
  - release - QA
  - hotfix - 버그의 빠른 수정

장점

배포 주기가 길고 팀의 규모가 큰 경우에 적합합니다.
rollback, hotfix, 운영배포 등 다양한 시나리오에 쉽게 대처 가능합니다.

단점

많은 수의 브랜치를 요구 → 관리의 어려움을 야기합니다.
nive는 2020년 3월에 그동안 못 꺼낸 이야기를 밝혔습니다.

Git-flow는 사람들이 표준처럼 다루기 시작할 정도로 많은 소프트웨어 팀에서 큰 인기를 누렸지만, 불행하게도 만병통치약으로 취급되기 시작했다.
“Web apps are typically continuously delivered, not rolled back, and you don’t have to support multiple versions of the software running in the wild.”

웹 애플리케이션은 일반적으로 롤백되지 않으며, 지속적으로 서비스를 제공하기에 소프트웨어를 다양한 버전으로 지원할 필요가 없다.
“This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.”

10년 전 블로그에 글을 쓸 때 이러한 소프트웨어를 염두하지 않았다. 만약 당신의 팀이 소프트웨어를 지속적으로 제공한다면 GitHub-flow와 같은 간단한 워크플로우 채택을 제안한다.
“Git-flow has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.”

정리 : 소프트웨어 버전 관리가 필요한 앱이나 솔루션에 적합한 워크플로우입니다. 웹 애플리케이션에서 Git-flow는 고려할 전략이 아닙니다.

■ GitHubFlow

특징

Github 에서 제공하였습니다.
master 브랜치를 중심으로 운영합니다.
기능 개발, 버그 수정 등의 작업용 브랜치를 구분하지 않는 단순한 구조입니다.
master 브랜치로부터 새로운 브랜치를 생성하여 작업합니다.
master 브랜치에 PR 요청합니다. PR 이란 Pull Request의 약자로 변경된 코드를 승인을 하거나 코드리뷰를 할 수 있는 단계입니다.
PR 승인을 받게 되면 master 브랜치에 merge
master 브랜치에 merge는 배포를 의미합니다.

장점

기능 구현 시나리오가 단순하여 편리
수시로 배포가 일어나는 프로젝트에 유용

단점

배포가 자동화 되어 있지 않으면 자주 배포해야 하여 번거로움
master 브랜치에서 production, staging, development, testing 등 다양한 환경에서 배포 시기가 다른 브랜치를 병합한 뒤 동시에 여러개를 배포하여 테스트하고 진행할 수 없음
- 개발서버와 운영서버가 분리된 환경에서 GithubFlow를 사용하면 작업 A와 B의 사전에 배포 시기를 논의해야하는 시간적 비용이 발생배포 시기가 다른 브랜치의 코드가 딸려나가는 경우가 발생

GitHub-Flow를 사용하는 회사의 예 - 뱅크 샐러드

GitHub-Flow를 사용하되 배포 방식만을 변경
GitHub-Flow 의 기존 배포 방식 : master에 commit이 merge 될 때마다 배포
Commit-Train Based Deployment 방식
- 마치 역에서 기차가 정차해 있다가 출발하는 모양과 비슷
- 여러 commit을 squash 해서 하나의 commit으로 만들어주고 master branch에 merge → merge 한 commit 을 모아 배포
이유 : 조직과 서비스가 커졌을 때를 대비한 확장성과 유연성을 가지기 위함
만약 하나의 Repository에 여러 가지 기능이 1분 간격으로 merge 되는 상황일 때, 최신 commit을 계속 배포한다면 어떻게 하면 될까요? 이러한 상황에도 유연성을 가지기 위해서 master에 merge 된 commit을 매번 배포하지 않음

예를 통해서 알 수 듯이 브랜치 전략에 정답은 없다. 주어진 환경에 맞게 수정하고 보완해가야 한다.

■ GitLabFlow

특징

복잡하지 않고 효율을 높이고자 생겨난 브랜치 전략
gitlab flow는 이슈트래킹을 연동해 프로세스를 단순화함
merge request를 통해 승인이 되는 브랜치만 merge

브랜치 종류
- feature
  - 모든 기능 구현은 feature 브랜치에서 진행
  - master 브랜치에서 나와 master 브랜치로 merge (수정)
  - 기능 구현이 완료되면 merge request를 보냅니다.
  - merge request에서 승인을 받으면 master 브랜치로 merge합니다.
- master
  - Gitlab-flow의 master 브랜치는 Git-flow의 develop 브랜치와 같습니다.
  - 작업이 완료된 feature 브랜치로부터 병합받습니다.
  - 기능에 대한 보장이 되었다면 production 브랜치로 머지합니다.
- production
  - 배포 브랜치입니다.
  - Git-flow의 master 브랜치와 같습니다.
  - 테스트 서버가 필요한 경우 pre-production 브랜치를 생성해 production에 병합하기 전에 test server에 배포해 확인 가능

체리픽으로 별도의 관리를 통해 배포가능

참고

화해기술블로그 - http://blog.hwahae.co.kr/all/tech/tech-tech/9507/
GitLab - https://docs.gitlab.com/ee/topics/gitlab_flow.html
Github - https://docs.github.com/en/get-started/quickstart/github-flow
https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/
우하한테크 유튜브채널
뱅크샐러드 기술블로그 - https://blog.banksalad.com/tech/become-an-organization-that-deploys-1000-times-a-day/
https://ko.wikipedia.org/wiki/%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC
버전관리 설명 블로그 - https://yoongrammer.tistory.com/17

저작자표시 (새창열림)