[Git & GitHub] - Git Flow Branch Strategy (Git 브랜치 전략)

Collaboration tools - Git & GitHub

 

 

1. Branch를 사용하는 이유?

(1) 브랜치를 사용하면 다른 브랜치에 영향을 받지 않는 독립적인 환경에서 특정한 기능을 개발하거나 버그 및 이슈 문제를 해결할 수 있다. 이처럼 브랜치를 사용하면 효과적으로 여러 기능을 여러 사람들이 병렬적으로 개발할 수 있도록 하는 환경을 제공해 주는 셈이다.

 

(2) 특정 기능을 개발할 때 브랜치 생성 후 코드를 작성하며 커밋을 남긴다. 개발이 완료된 경우 상위 브랜치 또는 메인 브랜치에 Merge를 하면 안전하게 기능을 개발할 수 있다.

 

(3) 기획 및 요구사항이 변경되어 기능이 필요가 없다면 관련된 브랜치를 삭제하면 안전하며, 이러한 부분을 이용해 테스트를 진행해 볼 수도 있고 테스트가 끝났다면 해당 브랜치를 삭제하면 된다.

 

(4) 하지만 이러한 전략도 규칙 없이 마음대로 사용한다면 혼란을 야기하거나, 원활한 협업 진행이 어려울 수 있다. 따라서 브랜치 관리에 명확한 기준을 갖고 협업을 하는 것이 중요하다. 아래에서 소개할 Git 브랜치 전략은 프로젝트의 Git 협업 브랜치를 효과적으로 관리하기 위한 Work-flow라고 보면 된다.  직접 브랜치 전략을 만들어서 프로젝트에 적용해 볼 수도 있겠지만, 이미 브랜치를 효과적으로 관리하기 위한 다양한 Best practice들이 존재하는데 대표적인 두 가지 유형인 Git Flow, GitHub Flow에 대해 소개하고자 한다.

 

 

 

 

 

 

 

 

 

2. Git Flow Strategy

 

 

Git Flow Strategy

 

2-1. Git Flow Strategy

(1) Git Flow 전략은 Vincent Driessen이 2010년에 공개한 A successful Git Branching Model이라는 글이 인기를 얻게 되며 대중적으로 많은 개발자들이 채택한 Branch strategy 중 하나이다.

https://github.com/nvie?tab=overview&from=2024-04-01&to=2024-04-15

nvie - Overview

 

(2) 이러한 Git Flow는 크게 Main(Master) Branch, Develop Branch, Supporting Branch 세 개로 구분하여 브랜치를 관리하게 된다. 이때 Supporting Branch는 다시 Feature Branch, Release Branch, Hotfix Branch로 구성된다.

 

(3) Main, Develop 브랜치는 개발 프로세스 전반에 걸쳐 항상 유지되는 브랜치이며, Supporting Branch에 속하는 Feature 브랜치는 필요한 상황에서만 생성하고 상황이 종료되면 해당 브랜치를 삭제한다. 이러한 메커니즘으로 협업자들이 병렬적으로 다양한 기능을 개발할 수 있는 것이다.

 

 

 

 

2-2. Main(Master) Branch 

(1) Main Branch 현재 사용자들이 실제로 사용 가능한 프로덕션 코드를 모아두는 브랜치 영역이다.

 

(2) 프로젝트 시작 시 생성되고 개발 프로세스 전반에 걸쳐 항상 존재하는 브랜치다.

 

 

 

 

2-3. Develop Branch

(1) 프로덕트의 다음 출시 버전을 개발하는 브랜치다.

 

(2) 해당 버전의 개발이 완료되면 Main 브랜치로 Merge 된다.

 

(3) 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 Develop 브랜치를 Main 브랜치에 Merge 한다. 평소에는 이 브랜치를 기반으로 개발을 진행한다.

 

 

 

2-4. Feature Branch

(1) 하나의 기능을 개발하기 위한 기능 브랜치로써 Develop 브랜치 하위 계층에서 생성된다. 하나의 기능 개발이 완료되면 Develop 브랜치로 Merge 할 수 있다.

 

(2) 협업 관계에서는 Merge 이전 Pull Request를 생성하여 Code review 후 일정 수 이상의 Approve를 받아야 Merge가 가능한 방식으로 많이 협업하고 있다.

 

 

 

 

2-5. Hotfix Branch

(1) 배포된 버전에 문제나 이슈가 있어서 이 부분을 해결해야 한다면 Hotfix 브랜치를 별도로 생성하여 문제를 해결한다. Main 브랜치에서 생성하고 문제나 이슈가 해결되면 Main 브랜치에 해당 내용을 Merge 한다.

 

 

 

 

 

 

 

3. 어떤 브랜치 전략을 사용해야 할까?

(1) 사실 해당 전략 이외에도 GitHub Flow, GitLab Flow 등 다양한 전략이 있지만 실제 프로젝트의 요구사항이나 규모, 제약조건 등을 잘 고려해서 적절한 브랜치 전략을 가져가는 것이 중요하다고 생각한다. 추후에도 다른 브랜치 전략에 대해 공부해 보고 정리할 기회가 있다면 포스팅해 보고자 한다.

 

 

 

 

 

 

4. Reference 

(1) https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

 

※ 해당 포스팅에 대해 내용 추가가 필요하다고 생각되면 기존 포스팅 내용에 다른 내용이 추가될 수 있습니다.

개인적으로 공부하며 정리한 내용이기에 오타나 틀린 부분이 있을 수 있으며, 이에 대해 댓글로 알려주시면 감사하겠습니다!