효율적인 깃 브랜치 전략 Git Flow - 1

 

협업 시 필수적인 깃을 효과적으로 사용하기 위해 다양한 깃 브랜치 전략이 존재한다. 그 중 팀의 규모가 크고 지속적인 개발&배포 사이클이 존재할 때 사용할 수 있는 Git Flow 전략에 대해 알아보자.

 

 

Git Flow

 

위 그림은 git flow하면 가장 유명한 그림이다. 지금 보면 저게 뭐지? 싶겠지만 개념을 알고 보면 한번에 이해가 갈 것이다. 그림에서 보이듯이 git flow에는 5개 종류의 branch가 존재한다. 각 브랜치의 이름과 간단한 역할은 다음과 같다.

 

main	제품으로 출시되는 브랜치
develop	다음 출시 버전을 개발하는 브랜치
feature	각 기능을 개발하는 브랜치
release	이번 출시 버전을 준비하는 브랜치 ex. 출시 전 QA 수행
hotfix	현재 출시 버전을 빠르게 패치하는 브랜치

 

여기서 main, develop 브랜치는 프로그램 개발 전반에 걸쳐 존재하지만, feature, release, hotfix의 보조 브랜치는 main 또는 develop 브랜치로부터 생성되어 일정 기간 동안만 존재한다. 이제 각 브랜치에 대해 조금더 자세히 살펴보자.

 

 

 

main 브랜치

main 브랜치는 release, hotfix 브랜치로부터의 병합(merge) 커밋으로만 구성되며 main 브랜치 내에서 직접 작업 커밋을 생성하지는 않는다. 즉 충분히 검증 및 테스트 후 출시 가능한 경우에만 main 브랜치에 병합되며 해당 병합 커밋에 버전 번호를 태깅하여 출시 버전 내역을 관리할 수 있다. 

 

 

develop 브랜치

다음 출시 버전을 개발하기 위한 브랜치로 develop 브랜치를 중심으로 다양한 추가 기능들이 개발된다. 출시된 버전만을 관리하는 main 브랜치와 달리 현재 개발하고 있는 기능들을 통합적으로 관리하는 브랜치로, 개발 시 develop 브랜치를 중심으로 병합이 활발하게 발생한다. 

 

 

feature 브랜치

새로운 기능 추가 시 develop 브랜치로부터 feature 브랜치를 생성하여 기능 개발을 수행한다. 즉 개발하고자 하는 기능별로 하나의 feature 브랜치가 대응되는 것이다. 해당 기능 개발이 완료되면 develop 브랜치에 병합 후 해당 feature 브랜치는 삭제한다. 만약 개발하고자 하는 하나의 기능이 더 세부적인 기능으로 분할 가능하다면 생성한 feature 브랜치로부터 다시 sub-feature 브랜치를 생성하고 개발 완료 후에는 feature 브랜치에 병합하는 방식으로 진행하면 된다. 

 

 

release 브랜치

출시할 만큼 충분히 기능이 개발된 경우 develop 브랜치로부터 release 브랜치를 생성한다. release 브랜치에서는 제품 출시를 위한 오류 수정, 문서 생성 등의 작업만을 수행하며 해당 브랜치에서 새로운 기능을 추가해서는 안된다. 출시 준비 완료 후 release 브랜치를 main 브랜치에 병합 후 해당 병합 커밋에 버전 번호를 태깅한다. 또한 다음 출시 버전 개발을 위한 develop 브랜치에 현재 release 브랜치에서 변경한 내용이 반영되어야 하므로 develop 브랜치에도 release 브랜치를 병합해준다. main, develop 브랜치에 모두 병합 후 해당 release 브랜치는 삭제한다. 

 

 

hotfix 브랜치

현재 출시된 버전에서 발생한 오류를 빠르게 수정하는 브랜치로 일명 '패치'를 만들어내는 브랜치이다. release 브랜치와 비슷한 것 같지만 release 브랜치는 develop 브랜치로부터, hotfix 브랜치는 main 브랜치로부터 생성된다. hotfix 브랜치도 마찬가지로 작업 완료 시 main 브랜치에 병합 후 해당 병합 커밋에 버전 번호를 태깅한다. 또한 오류 수정 코드를 현재 개발 중인 코드에도 반영해야 하므로 develop 브랜치에도 hotfix 브랜치를 병합해준다. main, develop 브랜치에 모두 병합 후 해당 hotfix 브랜치는 삭제한다.  

 

 

 

 

각 브랜치의 개념과 생성 방식을 파악한다면 별로 어렵지 않겠지만, 백문불여일견이라고 실제 간단한 개발 상황을 가정하고 해당 브랜치 전략을 적용해보자. 개발하고자 하는 프로그램은 다음과 같다.

화면에 "Hello World"를 출력하고 비프음을 5번 발생시키는 프로그램

 

 

일단 기본 main 브랜치에서 개발을 위한 develop 브랜치를 생성한다.

git checkout -b develop

 

 

우리가 개발하고자 하는 기능은 '메시지 출력', '비프음 발생'이므로 2개의 feature 브랜치를 생성한다. feature 브랜치의 이름은 통일성만 있다면 아무렇게나 지어도 상관없지만, 다음 글에서 설명할 Git Flow Extension Library에서 기본적으로 생성하는 feature 브랜치 이름은 'feature/<기능 이름>' 형태이므로 이렇게 생성해준다. 

git branch feature/print-message
git branch feature/generate-beep

현재까지 생성된 브랜치

 

 

 

 

이제 담당 개발자가 각 브랜치에서 개발을 진행하고 완료 시 develop 브랜치에 병합해준다. 두 feature 브랜치에서 개발 완료 시 커밋 그래프는 다음과 같다.

 

기능 개발 완료

 

 

먼저 feature/print-message 브랜치를 fast-forward 하지 않고 develop 브랜치에 병합해준다. 이 경우 커밋 그래프는 다음과 같다.

*fast-forward: 브랜치 병합 시 별도의 병합 커밋을 생성하지 않고 병합, 주 브랜치에서 보조 브랜치가 분기한 이후 주 브랜치에 변경사항이 없는 즉 커밋이 생성되지 않은 경우에만 가능

*--no-ff: fast-forward가 가능하더라도 항상 병합 커밋 생성하여 병합

git checkout develop
git merge --no-ff feature/print-message

feature/print-message 브랜치를 develop 브랜치에 병합

 

 

feature/generate-beep 브랜치도 fast-forward 하지 않고 바로 develop 브랜치에 병합해준다. 이 경우 커밋 그래프는 다음과 같다.

git merge --no-ff feature/generate-beep

feature/generate-beep 브랜치를 develop 브랜치에 병합

 

 

위와 같이 feature/generate-beep 브랜치를 바로 develop 브랜치에 병합하는 경우에는 커밋 그래프가 복잡해진다. 따라서 커밋 그래프를 단순하게 하기 위해 feature/generate-beep 브랜치를 develop 브랜치를 기준으로 rebase 해준다. rebase 후 feature/generate-beep 브랜치의 base 커밋이 develop 브랜치의 가장 최신 커밋으로 변경된다. (이에 따라 기존 feature/generate-beep 브랜치 내 모든 커밋 해시값 또한 변경된다. 7cc1759 → e42a73c, 5df33e8 → 276ee9c )

git checkout feature/generate-beep
git rebase develop

feature/generate-beep 브랜치 rebase

 

 

rebase 후 feature/generate-beep 브랜치를 develop 브랜치로 병합하면 다음과 같이 커밋 그래프가 보다 더 단순해진다. 

git checkout develop
git merge --no-ff feature/generate-beep

rebase 후 feature/generate-beep 브랜치를 develop 브랜치에 병합

 

 

모든 feature 브랜치를 develop 브랜치에 병합하였으므로 feature 브랜치를 모두 삭제해주자.

git branch -d feature/print-message
git branch -d feature/generate-beep

 

 

 

 

이렇게 기능 개발이 완료되면 출시 준비를 위해 develop 브랜치에서 release 브랜치를 생성한다. release 브랜치 또한 통일성만 있다면 아무렇게나 이름을 지어도 상관없지만 보통 'release/<버전 번호>' 형식을 따른다. 해당 release 브랜치에서 QA 작업을 수행 후 출시 준비가 완료되면 이를 main 브랜치에 병합 후 태그를 달아준다. develop 브랜치에도 마찬가지로 병합해준다. 

git checkout develop
git branch release/1.0.0

git checkout release/1.0.0
//QA 수행

git checkout main
git merge --no-ff release/1.0.0
git tag v1.0.0
git checkout develop
git merge --no-ff release/1.0.0

 

 

아래 커밋 그래프에서 dfd78ae 커밋이 main, develop 브랜치에 병합된 것을 확인할 수 있다. 또한 main 브랜치의 해당 병합 커밋에 v1.0.0 태그를 붙여주었다. 

 

release/1.0.0 브랜치를 main,develop 브랜치에 병합

 

 

병합 완료 후 마찬가지로 release 브랜치를 삭제해준다.

git branch -d release/1.0.0

 

 

 

 

출시한 프로그램에 오류가 발생하지 않으면 좋겠지만 아쉽게도 그럴 일은 없다. 이때 main 브랜치에서 hotfix 브랜치를 생성하고 해당 브랜치에서 오류를 수정한다. hotfix 브랜치 이름 또한 'hotfix/<버전 번호>' 형식을 따르며 작업 완료 후 main 브랜치에 병합 + 버전 번호 태깅, develop 브랜치에 병합을 해준다. 

git checkout main
git branch hotfix/1.0.1

git checkout hotfix/1.0.1
//패치 생성

git checkout main
git merge --no-ff hotfix/1.0.1
git tag v1.0.1
git checkout develop
git merge --no-ff hotfix/1.0.1

 

 

아래 커밋 그래프에서 3a706ed 커밋이 main, develop 브랜치에 병합된 것을 확인할 수 있다. 또한 main 브랜치의 해당 병합 커밋에 v1.0.1 태그를 붙여주었다. 

 

hotfix/1.0.1 브랜치를 main,develop 브랜치에 병합

 

 

마지막으로 병합을 모두 완료하였으니 hotfix 브랜치를 삭제해준다. 현재까지 남아있는 브랜치는 main, develop 뿐이다.

git branch -d hotfix/1.0.1

 

 

 

버전 별로 이와 같은 사이클을 돌며 개발을 진행하면 된다. Git Flow 전략은 다른 전략(GitHub Flow, GitLab Flow 등)에 비해 브랜치가 더 많고 복잡하다. 그러나 많은 브랜치들이 있기 때문에 팀의 규모가 크더라도 브랜치 별로 각자의 작업을 분리하여 동시에 개발을 진행할 수 있다는 장점이 있다.

 

이번 글에서는 git flow 전략을 구현하기 위해 git 명령어를 일일이 작성해주었다. 그러나 보다 편하게 git flow 전략을 구현할 수 있게 해주는 Git Flow Extension Library가 있다. 다음 글에서는 이 라이브러리를 활용하여 편하게 git flow를 적용해보자.

 

 

요약 

1. main, develop 브랜치는 개발 전반에 걸쳐 존재 / feature, release, hotfix 브랜치는 일시적으로만 존재

2. develop 브랜치는 main 브랜치로부터 생성 

3. feature 브랜치는 develop 브랜치로부터 생성 

4. release 브랜치는 develop 브랜치로부터 생성 

5. hotfix 브랜치는 main 브랜치로부터 생성 

6. feature 브랜치에서 작업 완료 시 develop 브랜치로 병합 후 삭제 

7. release 브랜치에서 작업 완료 시 main, develop 브랜치로 병합 후 삭제 

8. hotfix 브랜치에서 작업 완료 시 main, develop 브랜치로 병합 후 삭제 

 

 

 

끝.

 

 

 

참고

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

https://techblog.woowahan.com/2553/