Git Flow에 관하여

Git Flow

Vincent Driessen이 2010년에 제안한 브랜치 관리 전략으로, 소프트웨어 개발에서 자주 사용되는 Git 브랜치 관리 모델 중 하나이다. Git Flow는 특정한 브랜치 구조와 머지 전략을 사용하여 프로젝트의 안정성과 유연성을 높이는데 초점을 둔다.

 

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

 

Git Flow 구성 브랜치

1. Master 브랜치

Git 저장소에서 가장 중요한 브랜치 중 하나로, 프로덕션 환경에서 사용될 최종 코드를 담고 있는 브랜치다.

프로덕션 환경이란 실제 사용자들에게 서비스되는 환경을 의미한다. 

 

Master 브랜치의 특징

1) 안정성: Master 브랜치에 있는 코드는 항상 배포 가능한 상태여야 한다. 즉, 버그가 최소화되고, 기능이 완성되었으며, 성능이 검증된 코드만이 Master 브랜치에 병합되어야 한다. 이를 위해 테스트, 코드 리뷰 등이 Master 브랜치로 병합되기 전에 이루어져야 한다.

 

2) 릴리스 관리: Master 브랜치는 프로젝트의 릴리스 버전을 관리하는데 사용된다. 새로운 기능이나 버그 수정이 Master 브랜치에 병합될 때마다 새로운 버전 태그를 생성하여 릴리스 기록을 관리한다. 이를 통해 특정 시점의 코드 상태를 쉽게 확인할 수 있으며, 필요한 경우 이전 릴리스로 롤백하는 것도 가능하다.

 

3) 병합 전략: 일반적으로 Master 브랜치로 직접 커밋을 한느 것은 지양된다. 대신, 별도의 브랜치에서 작업을 수행하고, 해당 브랜치가 Master 브랜치의 기준을 만족할 때 Master 브랜치로 병합한다.

 

 

2. Develop 브랜치

Develop 브랜치는 프로젝트에서 새로운 기능들이 개발되고, 기존 코드에 개선 사항들이 추가되는 곳이다.

개발이 완료되면, Master 브랜치로 머지된다.

 

Develop 브랜치의 특징

1) 실험적인 개발: Develop 브랜치에서는 아직 프로덕션 환경에 배포되지 않은 새로운 기능들이 개발된다. 자유롭게 코드를 실험하고, 새로운 아이디어를 테스트하는 브랜치.

 

2) 협업: Develop 브랜치는 여러 개발자들과 협업하기에 적합한 공간이다. 각각 자신이 원하는 기능을 개발하기 위해 Develop 브랜치로부터 별도의 feature 브랜치를 만들고, 작업이 완료되면 Develop 브랜치에 병합한다.

 

3) 중간 통합: Develop 브랜치는 프로젝트의 중간 단계를 통합하는데 사용된다. 즉, 여러 feature 브랜치에서 개발된 기능들이 Develop 브랜치에 모이고, 이를 통해 큰 규모의 기능이나 변경 사항들이 하나로 통합된다.

 

4) 안정화: Develop 브랜치에 모아진 코드는 여전히 불안정할 수 있다. 따라서 코드를 추가적으로 테스트하고, 버그를 수정하여 안정화하는 작업이 이루어져야 한다.

 

5) 릴리스 준비: 코드가 안정화되면 Develop 브랜치의 내용은 별도의 release 브랜치로 분리되어 릴리스 준비가 이루어진다. release 브랜치에서는 마지막 테스트와 버그 수정이 이루어지며, 준비가 완료되면 Master 브랜치에 병합되어 배포된다.

 

 

3. Feature 브랜치

Feature 브랜치는 새로운 기능을 개발하기 위한 목적으로 사용된다. Develop 브랜치에서 분기되며 해당 기능이 개발되고, 테스트된 후에 다시 Develop 브랜치로 병합된다. Feature 브랜치를 사용하면 코드베이스에 큰 변화를 주지 않고도, 새로운 기능을 독립적으로 개발하는 데 유리하다. (네이밍은 feature/branch-name 과 같은 형태로 생성)

 

Feature 브랜치의 특징

1) 단일 기능 개발: 'Feature 브랜치' 이름에서도 알 수 있듯이, 특정 기능을 개발하기 위해 생성된다. 해당 기능과 관련된 코드만을 작성하며, 다른 기능이나 버그 수정 등은 다루지 않는다.

 

2) Develop 브랜치로부터 분기: Feature 브랜치는 기본적으로 Develop 브랜치로부터 분기되므로, 개발 중인 전체 코드베이스에 접근할 수 있다.(새로운 기능이 기존 코드와 호환)

 

3) 독립적인 작업 영역: Feature 브랜치를 사용하면 다른 팀원들의 작업으로부터 독립적으로 작업을 할 수 있다. 이는 코드 충돌을 최소화하는데 도움이 된다.

 

4) 코드 리뷰와 테스트: 기능 개발이 완료되면, 해당 브랜치는 코드 리뷰와 함께 품질을 검증, 기능이 올바르게 작동하는지 확인한다.

 

5) Develop 브랜치로 병합: 검증을 마친 Feature 브랜치를 Develop 브랜치로 병합한다. 이로써 새로운 기능이 다음 릴리스에 포함될 준비가 되었음을 의미한다.

 

 

4. Release 브랜치

Release 브랜치는 새로운 버전 릴리스를 준비하는 과정 중 중요한 역할을 한다. 

Develop 브랜치에서 분기되며, 해당 브랜치에서는 릴리스 준비를 위한 최종적인 버그 수정, 문서 작업, 테스트 등이 이루어진다. (네이밍은 release/v1.1 과 같은 형태로 생성)

 

Release 브랜치의 특징

1) Develop 브랜치로부터 분기: 릴리스를 준비하기 시작할 때, Develop 브랜치로부터 Release 브랜치를 생성한다. 이 시점의 Develop 브랜치는 새로운 기능들이 추가된 상태이며, 이를 기반으로 릴리스를 준비한다.

 

2) 최종적인 버그 수정과 테스트: Release 브랜치에서는 새로운 기능 추가는 하지 않으며, 기존의 코드에 대한 버그 수정, 테스트 등 릴리스에 필요한 최종 작업들을 수행한다.

 

3) 릴리스 준비: 이 단계에서는 릴리스 노트 작성, 버전 번호 업데이트 등 릴리스와 관련된 메타데이터를 준비한다.

 

4) Master 브랜치로 병합: Release 브랜치에서의 모든 준비가 완료되면, 이를 Master 브랜치로 병합한다.

 

5) Develop 브랜치로 병합: 릴리스 과정에서 Release 브랜치에 만들어진 변경 사항을 다시 Develop 브랜치로 병합한다. 이를 통해, 다음 릴리스를 준비하는 동안 이전 릴리스에서 이루어진 변경 사항들이 유지된다.

 

 

5. Hotfix 브랜치

Hotfix 브랜치는 프로덕션에서 발생한 버그를 긴급하게 수정하는데 사용된다. Master 브랜치로부터 분기되며, 수정이 완료되면 Master 브랜치와 Develop 브랜치로 병합된다. (네이밍은 hotfix/v1.0.1 과 같은 형태로 생성)

 

Hotfix 브랜치의 특징

1) 문제 해결: Hotfix 브랜치에서는 해당 문제에 대해 분석하고, 문제를 해결하는 코드 수정이 이루어진다. 일반적으로 이 과정은 빠르게 진행되어야 하며, 해당 문제와 관련된 부분만 수정을 수행하는 것이 좋다.

 

2) 테스트와 검증: 수정이 완료되면, 해당 수정이 문제를 정상적으로 해결했는지 테스트하고 검증한다. 이것이 중요한 이유는 수정사항이 프로덕션 환경에 배포되기 때문이다.

 

3) 버전 태그 생성: 테스트와 검증을 마치고, Master 브랜치로 병합하는 과정에서 새로운 릴리스에 대한 버전 태그를 생성한다. 이를 통해 문제가 수정된 새로운 버전을 나타낸다.

 

4) Develop 브랜치로 병합: Develop 브랜치와도 병합하여, 다음 릴리스에 해당 수정 사항이 포함되도록 한다. 이를 통해 다음 개발 과정에서도 동일한 문제가 재발하지 않도록 한다.

 

 

Git Flow가 필요한 이유

1. 코드의 안정성 유지

Git Flow를 사용하면, Master 브랜치는 언제나 배포 가능한 상태를 유지할 수 있다. 새로운 기능과 버그 수정은 별도의 브랜치(Feature, Release)에서 작업되고, 이들이 충분히 검증된 후에만 Master 브랜치에 병합되기 때문에 프로덕션에 배포되는 코드의 안정성을 높일 수 있다.

 

2. 병렬 개발

Feature 브랜치를 사용하여 여러 개발자들이 동시에 다양한 기능을 개발할 수 있다. 이를 통해 팀의 생산성을 높이고, 개발 프로세스를 유연하게 만들어준다.

 

3. 코드 기록

Git Flow를 사용하면 커밋과 브랜치의 히스토리가 체계적이고 명료해진다. 이를 통해 팀원들은 프로젝트의 상태와 진행 상황을 쉽게 이해할 수 있다.

 

4. 협업

Git Flow의 체계적인 구조 덕분에, 팀원들은 어떤 브랜치에서 작업해야 하는지, 어떻게 병합해야 하는지 등에 대한 명확한 가이드라인을 갖게 되므로 협업이 보다 원활하게 이루어진다.

 

 

 

Git Flow의 한계점

1. 복잡성

Git Flow의 전략은 여러 브랜치를 활용하여 코드의 버전을 관리한다. 이로 인해, 새로운 팀원이나 Git이 익숙하지 않은 사람들이 접근하기에는 복잡하게 느껴질 수 있다.

 

2. 빈번한 병합 충돌

여러 브랜치를 사용하는 구조 상, 브랜치 간의 병합이 빈번하게 발생하고, 이로 인해 충돌이 잦아질 수 있다. 이를 해결하는 과정에서 추가적인 시간과 노력이 필요하다.

 

3. 과도한 커밋

Git Flow의 구조로 인해 종종 불필요한 병합 커밋이 발생할 수 있다. 이것은 커밋 히스토리가 복잡해지고, 가독성이 떨어질 수 있다.

 

Git Flow를 적용하기 좋은 상황

1. 큰 규모의 프로젝트

큰 규모의 프로젝트에서는 여러 개발자들이 협업해야하며, 다양한 기능과 버그 수정들이 동시에 진행된다. Git Flow의 구조가 이러한 복잡한 작업을 체계적으로 관리하는데 도움이 된다.

 

2. 명확한 릴리스 사이클

프로젝트가 정기적인 릴리스 사이클을 가지고 있고, 각 릴리스가 명확한 버전 관리가 필요할 때, Git Flow의 Release 브랜치를 사용하여 릴리스 준비를 체계적으로 관리할 수 있다.

 

3. 긴 개발 주기

프로젝트의 개발 주기가 길고, 시간이 지나면서 코드베이스에 많은 변경사항이 쌓일 때, Git Flow의 체계적인 브랜치 관리가 유용하다.

 

 

 

Git Flow를 적용할 때는 복잡성과 병합 충돌의 가능성을 염두에 두고, 팀원들이 이해하고 적용할 수 있도록 교육 및 문서화를 철저히 해야한다. 또한, 프로젝트의 요구 사항이나 팀의 작업 방식에 따라 Git Flow 외에 다른 브랜치 전략이 더 적합할 수 도 있으므로, 상황에 맞는 최적의 전략을 선택하는 것이 좋다.

예를 들어 GitHub Flow, GitLab Flow 등이 있고, 이 브랜치 전략들은 보다 단순하고 유연한 방식을 제공하기도 한다.

 

 

 

Reference

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

https://hudi.blog/git-branch-strategy/

https://wnsgml972.gitbook.io/midas_log/contents/basiceducation/git