일반적으로 앱 개발 프로세스는 ‘기획 → 디자인 → 개발 → QA → 출시’ 순서로 진행됩니다. 하지만 개발 인원이 늘어나면서 개발의 절대적인 양과 시간이 증가하게 되었고, 여러 명의 실무자가 동시에 기능을 개발하는 것은 비효율적이라는 문제가 발생했습니다.
이러한 문제를 해결하기 위해 도입된 방식이 Git-flow입니다. 이는 Git 저장소를 효율적으로 운영할 수 있도록 설계된 브랜치 전략으로, 여러 개의 Git Repository를 운영하는 방식을 사용합니다.
Git-flow의 기본 구조
Git-flow는 다음과 같은 저장소와 브랜치를 운영하는 방식입니다.
저장소 구조
- 공유 저장소(A): 모든 개발자가 공유하는 저장소로, 최신 소스코드가 저장됩니다.
- 원격 개인 저장소(B): 공유 저장소를 Fork한 개인 저장소입니다.
- 로컬 개인 저장소(C): 개발자의 개인 컴퓨터에 저장된 저장소입니다.
이런 구조를 통해 개발자들은 공유 저장소에서 직접 기능을 구현하지 않고, 개인 저장소에서 작업한 후 검증된 코드만 공유 저장소에 반영할 수 있도록 합니다.
Git-flow의 주요 브랜치
Git-flow에서는 다음과 같은 주요 브랜치를 활용하여 협업을 진행합니다.
-
master 브랜치: 최종 배포가 이루어진 안정적인 코드가 저장됩니다.
-
develop 브랜치: 개발자들이 기능을 추가하고 버그를 수정하는 브랜치입니다.
-
feature 브랜치: 새로운 기능을 개발할 때 develop 브랜치에서 분기하여 생성됩니다.
-
release 브랜치: 배포 전 QA 테스트를 진행하는 브랜치로, QA 중 발견된 버그를 수정한 후 master와 develop 브랜치로 병합됩니다.
-
hotfix 브랜치: 배포된 버전에서 긴급하게 수정해야 할 문제가 발생하면 master 브랜치에서 분기하여 수정 후 다시 master와 develop에 병합됩니다.
Git-flow의 워크플로우
- develop 브랜치에서 새로운 feature 브랜치를 생성하여 기능을 추가합니다.
- 기능 개발이 완료되면 feature 브랜치를 develop 브랜치에 병합합니다.
- 여러 기능이 추가되었다면 QA를 위해 release 브랜치를 생성합니다.
- release 브랜치에서 발견된 버그를 수정합니다.
- QA가 완료되면 release 브랜치를 master와 develop 브랜치에 병합합니다.
- master 브랜치에 버전 태그를 추가하고, 이후 다시 develop 브랜치에서 개발을 시작합니다.
- 긴급한 버그 수정이 필요한 경우 hotfix 브랜치를 master에서 생성하여 수정한 후 다시 master와 develop에 병합합니다.
Git-flow의 장점과 단점
장점
- 체계적인 브랜치 전략을 통해 협업이 원활하게 이루어집니다.
- 안정적인 코드 관리가 가능하며, 기능별로 브랜치를 분리해 충돌을 최소화할 수 있습니다.
- 긴급한 버그 수정이 필요한 경우 hotfix 브랜치를 활용하여 빠르게 대응할 수 있습니다.
단점
- 작은 프로젝트에서는 불필요한 브랜치 관리가 추가되어 오히려 복잡도가 증가할 수 있습니다.
- 협업 인원이 적을 경우, Git-flow의 구조가 오버헤드가 될 수 있습니다.
결론
Git-flow는 개발팀이 효율적으로 협업할 수 있도록 돕는 강력한 브랜치 전략입니다.
특히 여러 명의 개발자가 동시에 기능을 개발하고 안정적인 배포를 원하는 환경에서 매우 유용합니다.
하지만 프로젝트 규모와 팀의 개발 방식에 맞춰 적절하게 활용하는 것이 중요합니다.
