Git-flow의 활용
회사에서 내부서버에 Gitlab을 활용하여 Git Server를 구축하여 형상관리를 하고 있는데 특별한 관리나 체계없이 브랜치 관리를 하다보니 히스토리 파악하기도 힘들기도 하고 형상관리를 제대로 하고 있다는 느낌이 들지 않아 효율적인 형상관리 시스템의 사용을 위하여 방법을 찾던 중 우아한형제들 기술블로그의 “우린 Git-flow를 사용하고 있어요” 라는 글을 보고 해당 전략을 도입하면서 각 브랜치에 대해 간략하게 정리를 해보았다.
Git-flow에는 5가지 종류의 브랜치가 존재한다. 항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있다.
master: 제품으로 출시될 수 있는 브랜치develop: 다음 출시 버전을 개발하는 브랜치feature: 기능을 개발하는 브랜치release: 이번 출시 버전을 준비하는 브랜치hotfix: 출시 버전에서 발생한 버그를 수정 하는 브랜치
가장 중심이 되는 브랜치는 master랑 develop 브랜치이며, 이 두 개 브랜치는 무조건 있어야 한다. 이름은 바뀔 수 있다만 웬만해서는 변경하지 않고 진행하도록 하자. Git도 Production에서 사용하는 브랜치는 master를 사용하게 되니 관련된 부분을 변경하면 새로운 사람이 왔을때 스터디 커브가 존재할 수 있다.
병합된 feature, release, hotfix 브랜치는 삭제하도록 한다. (클라이언트 툴에서 git flow제공한다면 merge 하면 삭제하는 옵션을 제공한다.)
Feature 브랜치
- 브랜치 나오는 곳 :
develop - 브랜치가 들어가는 곳 :
develop - 이름 지정 :
master,develop,release-*,hotfix-*를 제외한 어떤 것이든 가능.
새로운 기능을 추가하는 브랜치이다.feature브랜치는 origin에는 반영하지 않고, 개발자의 reop애만 존재하도록 한다.
여기서 머지를 할 때, --no-ff 옵션을 이용하여 브랜치에서 머지가 되었음을 git 기록에 남겨두도록 한다.
Release 브랜치
- 브랜치 나오는 곳 :
develop - 브랜치가 들어가는 곳 :
develop,master - 이름 지정 :
release-*
새로운 Production 릴리즈를 위한 브랜치이다.지금까지 한 기능을 묶어 develop 브랜치에서 release 브랜치를 따내고, develop 브랜치에서는 다음번 릴리즈에서 사용할 기능을 추가한다.release 브랜치에서는 버그 픽스에 대한 부분만 커밋하고, 릴리즈가 준비되었다고 생각하면 master로 머지를 진행한다. (이때도 --no-ff 옵션을 이용하여 머지하였음을 남긴다.)master로 머지 후 tag 명령을 이용하여 릴리즈 버전에 대해 명시를 하고, -s 나 -u <key> 옵션을 이용하여 머지한 사람의 정보를 남겨두도록 한다. 그런 뒤 develop 브랜치로 머지하여, release 브랜치에서 수정된 내용이 develop 브랜치에 반영한다.
Hotfix 브랜치
- 브랜치 나오는 곳 :
master - 브랜치가 들어가는 곳 :
develop,master - 이름 지정 :
hotfix-*
Production에서 발생한 버그들은 전부 여기로… 수정 끝나면, develop, master 브랜치에 반영하고, master에 다가는 tag 를 추가해준다.만약 release 브랜치가 존재한다면, release 브랜치에 hotfix 브랜치를 머지하여 릴리즈 될 때 반영이 될 수 있도록 한다.