[Git] Git-Flow에 대해

서론

지난 포스팅으로 gitignore로 불필요한 커밋을 방지하는 방법을 작성했다. 이제 Git 사용 준비가 끝났으니 실제 사용할 때는 어떤 식으로 사용하는 게 좋을지에 대해 작성해보려 한다. 개발자들 사이에서 한 번쯤은 들어봤을 법한 Git-Flow에 관해 정리해보려 한다.

 

Git-Flow?

단어 그대로 git의 흐름이라는 의미이다. git 관리 전략이라고 생각하면 좋을 것 같다.

Git-Flow가 필요한 이유는 협업하는 다른 개발자와의 코드 충돌 방지(conflict)를 위함이다.

Git-Flow는 branch를 어떻게 나누는지가 가장 중요하다고 생각한다.

 

branch의 종류

branch를 정리하면 아래와 같다.

• main(master) : 서비스 배포가 완료된 에러가 없는 branch
• develop(개발) : master에 merge 하기 전 작업이 완료된 branch
• feature(기능/작업) : 각 기능/작업 별 개발 branch
• release(출시) : 출시 전 최종 테스트를 위한 branch
• hotfix(긴급 에러) : 출시 버전에서 critical한 error가 발생했을 때 수정하기 위한 branch

위 5개 branch 중에서 main, develop은 필수이고, 나머지 branch는 필요에 따라 판단하여 생성하면 될 듯하다.

 

git-flow

 

Sample

사실 처음 위 그림을 접했을 때 이해가 잘 가지 않았다. 나와 비슷한 사람도 있을 것 같아 간단하게 예시로 정리해보려고 한다. 참고로 필자가 앱 개발자이기 때문에 앱 출시를 예로 들어서 설명하려고 한다.

 

App name : Go Git
app version : v1.2.0

 

위와 같이 예시를 잡고, 현재 구글 스토어에 업데이트 된 최신 버전이 v1.2.0인 Go Git이라는 앱에 기능 개선 작업이 들어왔을 때 아래와 같은 flow로 진행하면 된다.

이해를 돕기 위해 스토어에 업데이트 된 최신 버전이 에러가 없다고 가정하고, main branch에는 현재 v1.2.0에 대한 소스가 담겨있는 상태이다. 위에 설명한 대로 devleop에는 개발이 완료된 버전이 담겨있어야 하므로 현재 main과 develop에는 같은 소스가 담겨있는 상태이다.

메인 화면에 버튼 모양 바꿔주고, 서브 화면에 리스트 추가해 주세요!

 

위와 같이 2개의 작업이 들어왔다면, 2개의 feature branch를 각각 develop에서 파생시켜 만들어줘야 한다.

1.ex) gogit_PRJ111 / gogit_PRJ112 - PRJ111(메인 화면 버튼 모양 변경), PRJ112(서브 화면 리스트 추가) feature branch 생성

2. feature branch에서 기능 개발 후 테스트
3. 테스트 후 문제가 없다면 develop branch로 merge
4.  develop branch에서 apk 추출 후 스토어 출시
5. 에러가 발생한다면 develop branch에서 hotfix branch를 파생시켜 생성 후 2~4 flow 반복
6. 에러가 없다면 main(master) branch로 merge

 

이해를 돕기 위해 flow를 설명해 봤는데, 꼭 위와 같이 진행해야 되는 것은 아니고 필자가 자주 사용하는 방식이다.

release branch는 판단에 따라 추가해 주면 될 것 같다.

 

틀렸거나 부족한 내용이 있다면 댓글로 알려주시면 감사하겠습니다😊

 

Reference

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

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