Git branch 전략 (Git-Flow)

Git-Flow 전략이란?

배달의 민족 안드로이드 개발 파트에서 사용하고 있는 Git branch 전략으로

브랜치를 기능(feature), 릴리스(release), 핫픽스(hotfix) 등으로 구분하여 운영하는게 특징이다.

개발은 develop 브랜치에서 이루어지고, 테스트와 스테이징은 release 브랜치에서 이루어진다.

그리고 문제가 발생하면 핫픽스 브랜치에서 수정하여 메인 브랜치로 병합하게 된다. 

이미지 출처, 참고: https://techblog.woowahan.com/2553/

브랜치 종류

master : 최종 브랜치로 제품을 배포하는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 PR, Merge 한다
feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 PR, Merge 한다
release : 배포를 위해 master 브랜치로 보내기 전에 먼저 테스트와 스테이징을 하기위한 브랜치
hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치

방법

rebase 작업 대신 merge 작업으로 작업 도중 업데이트된 develop 브랜치를 반영한 경우

rebase 작업을 수행한 경우

1. master 브랜치에서 develop 브랜치를 분기합니다.
2. 개발자들은 develop 브랜치를 기준으로 브랜치를 분기합니다.
3. 각 구현해야 할 기능 마다 develop 브랜치에서 feature-* 브랜치로 분기합니다.
4. 작업 변경 사항을 최소단위로 feature-* 브랜치로 commit 합니다.
5. 기능을 개발하던 도중 다른 개발자의 PR혹은 커밋으로 develop 브랜치가 변화 했다면 rebase 하여 현재 브랜치의 커밋을 임시적으로 제거하고, rebase 대상 브랜치의 모든 커밋을 먼저 적용한 다음, 이전에 제거했던 커밋을 다시 적용해 작업합니다. (merge 와의 차이점은 선형적인 커밋 이력을 유지할 수 있다는 점 입니다.)
6. 기능 개발이 완료 되었다면 develop 브랜치로 PR 합니다.
7. 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치를 분기합니다.
8. 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영합니다.
9. 테스트가 완료되면 release 브랜치를 master와 develop에 merge합니다.
10. master 브랜치에서 버그 발생시 hotfix-* 브랜치로 분기하여 작업합니다. 이후 develop 브랜치와 master브랜치에 반영합니다.

장점

• 각 단계(개발, 스테이징, 배포 등)에 맞는 브랜치를 사용함으로써 작업을 체계적으로 관리할 수 있다.
• 복잡한 프로젝트에 적합하며, 큰 규모의 팀에서도 효과적으로 작동한다.

단점

• 많은 수의 브랜치를 관리해야 하므로, 브랜치 관리가 복잡해질 수 있다.
• 처음 해당 개발 흐름을 접할 때 이해가 어려울 수 있다. 

언제 사용하면 좋은가?

1. 복잡한 프로젝트를 관리 할 때
2. 정기적인 릴리즈 주기와 명확한 릴리즈 관리가 필요한 프로젝트인 경우