Gitflow 브랜치 전략 이해하기

많은 IT 기업에서 gitflow 를 사용해 버전 관리를 하고 있는 것으로 알고 있다.
나도 실제로 개발 업무을 진행하면서 Gitflow 를 통해 버전관리를 하고 있다.
하지만 Gitflow 가 무엇이고 어떻게 사용하고 어떤 전략을 통해 버전 관리를 하도록 권장하고 있는지 알아보기 위해 정리해보았다.
그럼 Gitflow 에는 어떤 브랜치들로 구성되어있고 어떤 전략으로 사용되는지 알아보자.

 

Gitflow 브랜치 구성

GitFlow 는 다음과 같은 브랜치들로 구성되어있다.

• main branch (기존 master 에서 main 으로 변경)
• develop branch 
• feature branch 
• release branch 
• hotfix branch 

 

 

그럼 각 브랜치들을 어떤 전략으로 사용해야하는지에 대해서 알아보자.

 

main(master) / develop branch

출처 - https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow#:~:text=What%20is%20Gitflow%3F,lived%20branches%20and%20larger%20commits.

 

하나의 main 브랜치 대신에 workflow 에서는 프로젝트의 히스토리를 기록하기 위해 2개의 브랜치를 사용한다.

 

main 브랜치는 공식적인 release 히스토리를 저장하고 develop 브랜치는 feature 브랜치를 통합하는 역할을 한다.
또한 main 브랜치에 태그를 사용해 버전을 기록하는 것도 하나의 방법이다.

 

따라서, main 브랜치는 보통 최종판 소스 코드라고 보면 된다.
그리고 develop 브랜치는 각 feature 브랜치를 통해 개발된 내용을 통합하는 역할을 하게 된다고 보면 된다.

 

 

feature branches

출처 - https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow#:~:text=What%20is%20Gitflow%3F,lived%20branches%20and%20larger%20commits.

 

각각의 새로운 기능들에 대해서는 백업이나 협업을 위해 각자의 브랜치를 가지고 있어야 한다.
하지만 feature 브랜치는 main 브랜치에서 생성하는 것이 아니라 각 feature 브랜치의 부모 브랜치로 develop 브랜치를 사용한다.
하나의 feature 가 완료되었다면 develop 브랜치로 merge 한다. 
그리고 feature 브랜치는 main 브랜치와 직접적으로 상호작용을 하면 안된다.

 

따라서, 각각의 새로운 기능을 만들 때 feature 브랜치를 생성해서 기능을 만들게 된다.
feature 브랜치는 main 브랜치가 아닌 develop 브랜치에서 생성해야 한다.
또한 여기서 중요한 점은 feature 브랜치를 생성할 때에는 가장 최근에 업데이트된 develop 브랜치에서 생성해야 한다는 것이다.
feature 브랜치에서 기능 개발이 완료되고나면 부모 브랜치인 devleop 브랜치에 merge 를 진행해야 한다.

 

feature 브랜치를 생성해서 개발을 진행하는 이유는 아무래도 협업을 하면서 다른 팀원과의 충돌을 막기 위함이 아닐까 생각한다.
그래서 각자 맡은 기능에 대해서 따로 feature 브랜치를 생성해서 각자의 브랜치에서 작업을 진행하게 된다.

 

 

release branches

출처 - https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow#:~:text=What%20is%20Gitflow%3F,lived%20branches%20and%20larger%20commits.

 

release 브랜치의 경우 develop 브랜치에서 충분히 기능 개발이 이루어진 시점에서 정해진 기간에 맞추어
develop 브랜치에서  release 브랜치를 생성한다.
release 브랜치에서 출시를 위한 준비 작업을 진행하게 된다. 이 때 이후 버전에 대해서는 별도로 개발을 진행하면 된다.
출시 준비가 완료되면 release 브랜치를 main 브랜치에 merge 하고 develop 브랜치에도 merge 하고나서 release 브랜치를 삭제한다.

 

정리해보면 release 브랜치는 보통 정식 출시를 앞둔 상태에서 목적으로 정해놓은 기능들이 완료된 시점에서 브랜치를 생성하게 된다.
그리고 개발된 기능들을 점검하고 준비하는 과정을 거치게 되고 출시해도 문제가 없다고 판단된다면 main 브랜치에 merge 하면서 출시가 이루어지게 된다.
이때 release 브랜치에서 준비하는 과정에서 수정사항이 생겼을 경우가 생길 수 있어 develop 브랜치에도 merge 를 진행해준다.

 

 

hotfix branches

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow#:~:text=What%20is%20Gitflow%3F,lived%20branches%20and%20larger%20commits.

 

hotfix 브랜치는 production release 가 된 상태에서 빠르게 패치를 진행하기 위해서 사용한다.
여기서 중요한 점은 hotfix 브랜치는 devleop 브랜치에서 생성하는 것이 아닌 main 브랜치에서 생성해야 한다.
hotfix 브랜치에서 수정하고나서는 main 브랜치와 develop 브랜치에 모두 merge 해야 한다.
그리고 main 브랜치의 태그는 업데이트 버전이 생성되어야 한다.
hotfix 브랜치를 만들어서 사용하는 이유는  버그를 수정하기 위해서 workflow 의 간섭이나 다음 release 를 기다릴 것 없이 바로 적용이 가능하다.

 

정리해보면 hotfix 브랜치는 production 에서 발생한 문제를 빠르게 처리하기 위해 생성하는 브랜치이다.
main 브랜치에서 생성해서 수정하게 되고 수정 사항에 대해서 main 브랜치와 develop 브랜치에 둘 다 merge 해줘야 한다.

 

 

정리

이렇게 Gitflow 에서 사용되는 각 브랜치에 대해서 정리해보았다.
내가 Gitflow 에 대해서 정리하게 된 이유는 어떻게 브랜치를 생성해서 merge 하고 하는 것에 대해서 헷갈리기도 했고
계속해서 이렇게 하는 것이 맞는건가? 하는 생각도 많이 들었기 때문에 Gitflow 를 어떤 목적에서 만들었고 어떻게 사용하기를 권장하고 있는지 알고 싶었고 앞으로 어떤 전략으로 진행하면 좋을지에 대해서도 생각해보고 싶었기 때문이다.

 

물론 Gitflow 브랜치 전략을 반드시 사용해야 하는 것도 아니고 브랜치를 관리하는데에는 많은 전략들이 있다.
많은 기업들에서 Gitflow 를 사용하고 있었기 때문에 사용해보려고 한 것이었고 Gitflow 라는 브랜치 전략을 사용해보면서 
팀에 맞게 변경해 나가는 것도 중요한 과제라고 생각한다.

 

 

- 참고 사이트

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow#:~:text=What%20is%20Gitflow%3F,lived%20branches%20and%20larger%20commits.

Gitflow Workflow | Atlassian Git Tutorial

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

A successful Git branching model