안녕하세요!
보통 혼자 작은 작업을 할때는 세부 브랜치를 관리하기 보다
TBD처럼 단일 브랜치를 관리하는게 편해서 자주 사용했었습니다.
하지만 프로젝트 규모가 큰 현업에서는 더 안정적인 브랜치 전략인
Git-Flow 형식을 대부분 쓴다고 합니다.
그래서 이번에는 Git Flow 브랜치 전략에 대해 알아보고 실제로
어떻게 적용했는지 이야기해보려고 합니다!
1. 브랜치의 종류
- Main: 배포 가능한 상태의 코드가 있는 브랜치.
- Develop: 개발된 작업이 모이는 개발 브랜치.
- Feature: 개발 작업이 진행되는 작업 브랜치.
- Release: 배포 준비를 위한 브랜치.
- Hotfix: 빠른 버그 수정을 위한 브랜치.
이 중에서 Main과 Develop이 핵심 브랜치로 상시 존재하며
나머지 브랜치는 상태 관리를 위해 생성되고 사라집니다.
2. 작업 흐름
작업 흐름은 위의 그림처럼 Feature -> Develop -> Relase -> Main ( -> HotFix )순입니다.
- Feature에서 기능 단위로 작업을 합니다.
예를 들어 제가 A라는 기능을 작업했다고 가정해봅시다.
제가 작업한 코드를 Develop에 병합(Merge)합니다.
(작업이 완료된 Feature 브랜치는 삭제될 수 있습니다.)
-> Devleop에 작업한 코드들이 모입니다.
동료 분들이 B와 C작업을 해서 Develop에는 A,B,C가 모였습니다!
A,B,C 정도면 이제 배포를 진행하려고 합니다.
Develop 브랜치에서 Release를 땁니다!
-> Release에서 이제 배포를 준비합니다.
혹시 존재할지도 모르는 에러를 체크하고
코드를 다시 점검하는 등 안정화 작업을 합니다.
이제 진짜 배포를 하기로 결정되었습니다.
-> Main에서 이제 배포를 시작합니다.
서비스가 출시되었습니다!
앗, 그런데 미처 Release 브랜치에서 발견하지 못한
버그가 발생했습니다.
Main에서 HotFix 브랜치를 땁니다...
(-> HotFix) 빠르게 버그를 잡습니다.
작업이 완료되면 이 코드를 다시
Main과 Develop에 병합(Merge)합니다.
3. 적용 사례
제가 이번에 MVP 패턴을 학습하며 적용한 Git Flow 적용 사례입니다!
GitHub 로그인을 하고 유저를 검색하는 간단한 프로젝트 입니다.
제 작업을 큰 덩어리로 나누면 이렇습니다.
1. Feature 브랜치에서 기능 단위로 작업 후 Develop에 병합
기능 구현은 깃 로그인, 유저 검색과 뷰 작업까지 완료된 상태입니다.
(실제로는 더 작은 단위로 브랜치를 만들어야 할 것 같습니다.)
Feature/Network 브랜치 (작업 후 Develop에 병합)
Feature/View 브랜치 (작업 후 Develop에 병합)
Feature/Presenter 브랜치 (작업 후 Develop에 병합)
2. Develop 브랜치에서 Release 브랜치 생성
작업물이 1차 배포 상태라고 가정하고 Release 브랜치를 생성했습니다.
3. Release 브랜치에서 안정화 후(생략) Main 브랜치에 병합(Merge)
원래 배포준비 작업을 해야하지만 생략하고 바로 Main 브랜치에 병합했습니다.
4. Main 브랜치에서 문제 발생 확인 후 HotFix 브랜치 생성
화면을 눌렀을 때 키보드가 내려가는 로직이 없는 것을 에러로 가정했습니다.
HotFix에서 해당 로직을 추가하고 Main과 Develop에 병합했습니다.
5 ~ . 1번 ~ 4번 반복
다시 Feature 브랜치에서 기능 단위로 작업하고 위 내용을 반복했습니다.
참고로 저는 일부러 페이징 처리와 검색어가 없을 때 보이는 EmptyView() 작업을
하지 않고 남겨놓았다가 처리했습니다.
(작업 내역 - GitKraken 사용 중입니다.)
Release 브랜치를 v1.0.1에서 새로 만들어야 했는데 기존 브랜치에서 병합했네요...
혹시 틀린 내용이 있다면 알려주시면 감사하겠습니다!
읽어주셔서 감사합니다~
아래는 Git Flow로 작업해본 프로젝트 링크입니다!
https://github.com/kangsworkspace/MVPProjectWithGitAPI