git flow 전략

오늘 얘기가 나왔던 내용인데, 팀 내에서 해보고자 하는  git flow 전략을 정리해본다.

정리하면서도 100% 이해가 된 상태가 아니라서 직접해보고 수정할 부분이 생긴다면 수정하는걸로~!

 

브랜치 역할 및 사용 방법

main

릴리즈 배포 브랜치

 

release

다음 릴리즈 배포할 버전을 준비하는 브랜치

main 에서 1.0.0이 배포되면 다음 배포버전인 1.1.0을 준비하는 브랜치이다.

develop에서 배포할 기능을 release에 rebase하여 배포할 버전을 준비한후 배포할때 main브랜치로 머지한다.

QA 에서 나온 이슈들을 이 브랜치에서 수정하고 이 부분들을 develop에도 머지해주어야 한다.

 

develop

다음 출시할 버전을 개발하는 브랜치.

feature에서 개발이 완료된 작업들을 PR을 통해 develop에 머지한다. 이때는 하나의 커밋로그가 하나의 Task가 될 수 있게 Squash 머지를 한다.

develop에서 배포할 기능의 커밋을 선택하여 release에 rebase한다. 즉 release에서 develop 을 머지한 후(push 안한상태) release 브랜치에서 rebase 하여 포함할 기능의 커밋로그만 pick하고, 포함하지 않을 커밋로그는 drop 하여 반영한다.

 

feature

기능 개발 브랜치

여러개의 기능을 병렬로 개발시 feature 브랜치는 기능 단위로 여러개가 생성 될 수 있다.

develop으로 PR 할때 너무 큰 단위가 되지 않게, feature를 이루는 Task 를 작게 쪼갠다.

예를 들어 로그인 기능 개발이라고 한다면, 구글로그인 개발/애플로그인 개발과 같이 2개의 Task로 나누어 각각의 feature에서 개발을 진행한다. 즉 한개의 Task - feature 가 1:1 로 될 수 있게 한다. Task 관리는 지라를 통해서 하며, 커밋 로그에 반드시 Task 링크를 적는다. (JIRA의 경우에는 커밋로그에 이슈번호를 작성하면 자동으로 링크 연결이 된다)

개발이 완료되면 develop에 PR로 머지한 다음 feature 브랜치는 지운다.

PR 을 요청하기 전에 develop에 변경 사항이 있을 수 있으니 develop에 있는 작업을 먼저 feature에 머지해야 하는데 이때는 feature 브랜치에서 develop을 rebase하고 그 이후에 PR을 요청한다.

PR을 리뷰어하고 머지를 승인 하는 사람은 이때 커밋로그가 간략해질 수 있게 squash 머지를 한다.

 

hotfix

릴리즈 배포된 버전에서 급하게 이슈 수정을 해야 할 경우 hotfix에서 수정 후, main에 PR로 머지한다. 이때 develop에도 같이 머지 한다.