[Git] Git Branch 전략 - git-flow

📌 브랜치 전략을 배우는 이유

 

여태 프로젝트를 진행하면서 메인 브랜치에서 모든 작업을 수행했다. 사실 혼자 개발을 진행하면 딱히 엄청 큰 문제가 생기는 건 아니지만 팀 프로젝트라면 문제가 많다.. 잦은 충돌은 당연하고 히스토리가 섞여 추적하기도 어렵다. 또 브랜치가 어떤 목적으로 생성되었는지 어떤 브랜치를 병합해야 하는지 등 혼란이 생길 수밖에 없다. 더 나은 협업을 위해 브랜치를 어떻게 생성하고 관리하면 좋은지 정리해보고자 한다.

 

 

📌 브랜치 전략

브랜치는 다른 브랜치에 영향을 받지 않고 독립적으로 개발이 가능하게 해 준다. 여러 명의 개발자가 하나의 저장소를 사용할 때 브랜치를 효과적으로 활용하기 위한 work-flow가 브랜치 전략이다.

브랜치 전략에는 여러 가지가 있는데 프로젝트의 규모나 특성에 따라 적절한 브랜치 전략을 채택해 사용하면 된다.

대표적인 git-flow, github-flow를 살펴보자

 

 

🗂️ Git-flow

2010년도에 한 개발자가 제시한 모델로 대중적으로 사용되고 있는 브랜치 전략이다. 

git-flow는 5종류의 브랜치를 사용, 크게 메인과 보조 브랜치로 구분하여 브랜치를 관리한다.

주요 브랜치는 항상 유지되는 브랜치로 master(main)와 develop로 구성되어 있고

필요에 따라 생성하고 병합하는 보조 브랜치는 feature, release, hotfix로 구성되어 있다.

main	master(main)	제품을 배포하는 브랜치
	develop	다음 배포 버전을 개발하는 브랜치
support	feature	단위 기능을 개발하기 위한 브랜치
	release	배포를 위한 브랜치로 QA, 테스트 진행
	hotfix	배포 버전에서 생긴 버그를 긴급 수정하기 위한 브랜치

 

🔎 주요 브랜치

master (main)

배포했거나 곧 배포할 프로덕션 코드를 모아두고 관리한다.

 

develop

다음 배포 버전을 개발하는 브랜치

develop의 코드가 안정되고 배포할 준비다 되면 master로 병합하고 배포버전으로 태그 예) v0.1

 

 

🔎 supporting 브랜치

기능을 구현하고 배포 준비, 배포한 제품이나 서비스의 버그 해결을 위한 브랜치

 

feature

기능을 개발하는 브랜치

develop 브랜치에서 생성해 기능을 완성될 때까지 유지되고 완성되면 develop에 병합된다.

개발자 저장소에만 존재하고 origin에 push 하지 않음

❗️Fast-Forward로 merge 하지 않는다(Fast-Forward 병합하면 커밋 히스토리가 기능별로 나눠지지 않아 파악이 어려워짐)
❗️develop에서 생성해 develop로 merge

✅ feature 브랜치 만들기

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

 

✅ develop에 merge 하기

$ git checkout develop
Switched to branch 'develop'

$ git merge --no-ff myfeature  ## merge 커밋을 만들어 merge하기
Updating ea1b82a..05e9557
(Summary of changes)

$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).

$ git push origin develop

 

release

제품 배포를 준비하는 브랜치

develop 브랜치가 배포해야 할 기능이 모두 merge 되어있고 배포할 상태가 되었으면 release 브랜치를 만든다.

배포하는데 필요한 버전 넘버, 빌드 일정 등의 메타 데이터 준비나 자잘한 버그를 해결하고 QA, 테스트 진행

테스트를 진행하며 발견된 버그의 수정은 develop에도 적용해야 함

배포 준비가 완료되면 main 브랜치에 merge 한다.

❗️develop에서 생성해 develop, master로 merge

❗️브랜치명은 release-*으로 생성

✅ release 브랜치 생성

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"

$ ./bump-version.sh 1.2 ## bump-version.sh 버전넘버가 들어가 있는 파일을 전부 수정하는 가상의 쉘 스크립트
Files modified successfully, version bumped to 1.2.

$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

 

✅ release 브랜치 merge 하기

1) master에 merge

$ git checkout master
Switched to branch 'master'

$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

$ git tag -a 1.2 ## tag 달아주기

 

2) develop에 merge

$ git checkout develop
Switched to branch 'develop'

$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

 

 

✅ release 브랜치 삭제

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

 

 

hotfix

이미 배포한 운영 버전에서 발생한 버그를 수정하는 브랜치

❗️master에서 생성해 master로 merge

❗️브랜치명은 hotfix-*로 생성

✅ hotfix 브랜치 생성

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"

$ ./bump-version.sh 1.2.1 ## 버전 넘버 변경!
Files modified successfully, version bumped to 1.2.1.

$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

 

✅ 버그 해결

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

 

✅ master에 merge

1) master에 merge

$ git checkout master
Switched to branch 'master'

$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

$ git tag -a 1.2.1

 

2) develop에 merge

$ git checkout develop
Switched to branch 'develop'

$ git merge --no-ff hotfix-1.2.1
erge made by recursive.
(Summary of changes)

 

✅ hotfix 브랜치 삭제

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).

 

📌 git-flow 장단점

장점

브랜치 구조가 명확하게 구분되어 있어 규칙성이 있다

브랜치 별로 역할이 나눠져 있어 병렬적으로 개발을 진행할 수 있어 소스 프리징이 없다

태그를 사용해 버전을 관리하기 때문에 쉽게 확인 가능하고 롤백이 용이하다

hotfix 브랜치를 통해 배포된 제품의 버그를 빠르게 수정할 수 있다

release 브랜치를 통해 QA와 테스트를 진행하기 때문에 배포 안정성이 높다

 

단점

브랜치 역할이 명확하게 구분되어 있어 유연하지 않다

다양한 브랜치 사용으로 인해 복잡하고 적응 기간이 필요하다

feature-develop-release-master 순으로 진행되다 보니 속도가 느리다

 

 

❓git-flow는 웹에 적합하지 않다?

git-flow를 처음 제안했던 개발자가 2020년에 새로운 내용을 추가했는데 내용을 간단하게 정리해 봤다.

웹 애플리케이션은 롤백되지 않고 지속적으로 제공되며 여러 버전의 소프트웨어가 동시에 실행되도록 지원할 필요가 없다
...
지속적 배포(continuous delivery)를 수행하는 경우 git-flow보다 간단한 github-flow를 채택하는 것을 제안한다.
하지만 명시적으로 버전이 지정된 소프트웨어를 빌드하거나 여러 버전의 소프트웨어를 지원하는 경우는 git-flow가 적합할 수 있다.

 

결론은 git-flow는 정기 배포와 버저닝이 필요한 애플리케이션에 적합하다!

 

 

 

 

 

 

 

참고

A successful Git branching model

[번역]A successful git branching model