소프트웨어 개발을 위한 브랜치 전략

개요

브랜치 전략은 여러 개발자가 협업할 때 코드를 효율적으로 관리하기 위한 방법입니다. 브랜치 전략은 다양한 종류가 있으며, 각각의 특징에 따라 적합한 브랜치 전략을 선택하여 사용해야 합니다. 이번 블로그 포스트에서는 브랜치 전략의 종류와 사용법에 대해서 알아보도록 하겠습니다.

git-flow 전략

git-flow 브랜치 전략은 Vincent Driessen에 의해 제안된 브랜치 전략입니다. 브랜치 전략 중에서 가장 유명한 브랜치 전략으로써 많은 회사가 사용하고 있습니다.

https://nvie.com/posts/a-successful-git-branching-model/

git-flow 브랜치 전략은 master, develop, feature, release, hotfix 브랜치로 구성되어 있습니다.

master 브랜치
- master 브랜치는 항상 제품으로 출시할 수 있는 안정적인 코드를 유지하는 데 사용됩니다.
- 배포 가능한 버전은 이 브랜치에서 Tag로 관리됩니다.
develop 브랜치
- develop 브랜치는 다음 릴리스를 위해 개발하는 코드를 포함합니다.
- 새로운 기능과 버그 수정을 할 브랜치는 여기에서 만듭니다.
feature 브랜치
- 새로운 기능을 개발하기 위한 브랜치로, develop에서 만듭니다.
- 각 기능은 별도의 브랜치로 개발을 하고, 개발이 완료되면 develop 브랜치에 병합합니다.
release 브랜치
- 릴리스를 준비하는 단계에서 사용하는 브랜치로, develop 브랜치로부터 만듭니다.
- 배포 준비 작업(버전 번호 업데이트, 문서 등)을 수행하고 테스트를 진행한 후 master 및 develop 브랜치에 병합합니다.
hotfix 브랜치
- 긴급한 버그 수정을 하기 위한 브랜치입니다. master 브랜치로 만듭니다.
- 수정이 완료되면 master와 develop 브랜치에 병합합니다.

git-flow에서는 release 브랜치가 master에 병합될 때, hotfix 브랜치가 master에 병합될 때 릴리스됩니다. 그런 다음 Git tag를 사용하여 출시된 시점을 관리합니다.

GitHub flow 전략

GitHub flow는 쉽고 직관적인 Git 브랜치 전략 중 하나로 GitHub이 제안하였습니다. 이 전략은 주로 웹 개발에서 릴리스 관리를 위한 간단한 워크플로우를 제공합니다.

https://docs.github.com/get-started/using-github/github-flow

GitHub flow 브랜치 전략은 master, feature 브랜치로 구성되어 있습니다.

master 브랜치
- master 브랜치는 항상 제품으로 출시할 수 있는 안정적인 코드를 유지하는 데 사용됩니다.
feature 브랜치
- 새로운 기능을 개발하기 위한 브랜치로, master에서 만듭니다.
- 이 브랜치로 코드를 수정하고 커밋합니다.
Pull Request (PR)
- 기능과 작업이 끝나면 개발자는 master 브랜치에 병합하기 위해 Pull Request를 만듭니다.
- 코드 리뷰나 테스트를 통과하지 않으면 병합할 수 없습니다.
코드 리뷰와 테스트
- 다른 개발자는 Pull Request를 검토합니다.
- 자동화된 테스트를 통과하면 코드가 안전한 것으로 간주됩니다.
Merge
- Pull Request가 모든 조건에 도달하면 master에 병합됩니다.

GitHub flow에서는 feature 브랜치가 master에 병합되면 릴리스됩니다. GitHub flow에서는 자주 출시하는 것이 중요하며 사용자에게 빨리 새로운 기능과 버그 수정을 제공할 수 있습니다.

GitLab flow 전략

GitLab flow는 GitLab이 제안한 브랜치 전략입니다. GitLab flow는 기본 GitHub flow와 동일합니다. 그러나 출시할 타이밍이 있는 경우(iOS 앱 배포에는 앱 심사가 있으며, 정기적으로 배포를 하는 서비스 등이 이에 해당합니다), 사용할 수 있는 전략입니다.

https://docs.gitlab.co.jp/ee/topics/gitlab_flow.html

GitLab flow 브랜치 전략은 master, feature 브랜치와 배포를 위한 브랜치(production, staging등)로 구성되어 있습니다.

master 브랜치
- master 브랜치는 항상 제품으로 출시할 수 있는 안정적인 코드를 유지하는 데 사용됩니다.
feature 브랜치
- 개발자가 새로운 기능과 작업을 할 수있는 브랜치로 master 브랜치에서 만듭니다.
- 이 브랜치로 코드를 수정하고 커밋합니다.
Merge Request
- 기능과 작업이 끝나면 개발자는 master 브랜치에 병합하기 위해 Merge Request를 만듭니다.
- 코드 검토 및 테스트를 통과하면 병합이 가능합니다.
코드 리뷰와 테스트
- 다른 개발자가 Merge Request를 검토합니다.
- 자동화된 테스트가 통과되면 안전하다고 생각할 수 있습니다.
production(stable, staging) 브랜치
- production(stable, staging) 환경에 배포 가능한 안정적인 코드를 가지는 브랜치입니다.
- 배포하기 위해 만드는 브랜치로 마스터 브랜치에서 만듭니다.
hotfix 브랜치
- GitLab flow에는 hotfix 브랜치가 없습니다. 문제가 있으면 master 브랜치에서 브랜치를 만들어 master 브랜치에 병합합니다. 그런 다음 릴리스 브랜치에 Git의 cherry pick 기능을 사용하여 production 브랜치에 병합합니다.

GitLab flow는 릴리스 타이밍이 있는 경우 사용할 수 있는 브랜치 전략입니다. 개발한 내용(feature 브랜치)은 master 브랜치에 병합하여 배포가 필요한 타이밍에 master 브랜치에서 production(stable, staging) 브랜치를 만들어 배포합니다.

Trunk-Based Development 전략

Trunk-Based Development(TBD) 전략은 신속한 소프트웨어 릴리스와 높은 협업을 목표로 하는 간단하고 효과적인 Git 브랜치 전략입니다. TBD 전략은 지속적인 통합(CI)과 지속적인 배포(CD)를 강조합니다.

https://trunkbaseddevelopment.com/

TBD 브랜치 전략은 하나의 브랜치(trunk, master, main)로 구성되어 있습니다.

Branch strategy - Trunk-Based Development

하나의 브랜치(trunk, master, main)
- TBD에서는 주로 master(main) 브랜치만 사용합니다. master 브랜치는 항상 제품으로 출시할 수 있는 안정적인 코드를 유지하는 데 사용됩니다.
빈번한 커밋
- 개발자는 작은 단위로 자주 커밋을 합니다. 이 코드의 변경 사항을 빠르게 공유하여 지점 간 충돌이 발생하지 않도록 합니다.
Pull Request 대신 직접 커밋 및 코드 검토
- 작은 변경 사항에 대해 Pull Request를 만드는 대신 master 브랜치에 직접 커밋하여 코드 검토를 진행합니다. 이것은 분기 간 충돌을 최소화할 수 있습니다.
릴리스
- master에 직접 커밋을 하기 때문에, 릴리스는 타이밍을 정해 실시합니다.

TBD는 24시간 이내에 모든 멤버가 커밋을 하도록 합니다. 다시 말해, 24시간 이내에 커밋할 수 있을 정도로 작은 코드를 자주 작성하는 것이 중요합니다.

TBD는 구글이 사용하는 것으로 유명합니다.

Scaled Trunk-Based Development 전략

Scaled Trunk-Based Development(STBD) 전략은 Trunk-Based Development 전략과 동일하지만 master 브랜치에 직접 커밋을 하지 않고 feature 브랜치를 만들고 커밋한 후, feature 브랜치를 master에 병합합니다.

https://trunkbaseddevelopment.com/

STBD 브랜치 전략은 TBD와 동일하게 하나의 브랜치(trunk, master, main)와 feature 브랜치로 구성되어 있습니다.

하나의 브랜치(trunk, master, main)
- STBD에서는 주로 master(main) 브랜치만 사용합니다. master 브랜치는 항상 제품으로 출시할 수 있는 안정적인 코드를 유지하는 데 사용됩니다.
feature 브랜치
- 작은 커밋을 하기 위한 브랜치로 짧은 라이프 사이클을 가지는 브랜치입니다.
릴리스
- master 브랜치만 관리하므로, 릴리스는 타이밍을 정해 실시합니다.

TBD는 master 브랜치에 직접 커밋을 하고, 코드 리뷰를 함으로 자체적인 개발 체계가 필요합니다. STBD는 TBD의 장점을 사용하면서, 이런 자체적인 체계를 구성하기 힘든 경우에 사용할 수 있는 브랜치 전략입니다.

완료

이것으로 소프트웨어 개발을 위한 브랜치 전략과 그에 대한 사용법에 대해 간단히 알아보았습니다. 자세한 내용은 각 브랜치 전략에 대한 링크를 통해 확인할 수 있습니다.

브랜치 전략은 개발자들이 협업할 때 코드를 효율적으로 관리하기 위한 방법입니다. 브랜치 전략은 다양한 종류가 있으며, 어떤 브랜치 전략이 더 좋고 나쁘다고 말할 수 없습니다. 각각의 프로젝트와 팀에 맞는 브랜치 전략을 선택하여 사용하거나 이 브랜치 전략을 기반으로 자신만의 브랜치 전략을 만들어 사용하면 좋지 않을까 생각합니다.

Github Sponsor

Buy me a coffee

제 블로그가 도움이 되셨나요? 하단의 댓글을 달아주시면 저에게 큰 힘이 됩니다!