Git-Flow.md

GitFlow

Git-flow는 기능이 아니라 서로간의 약속인 방법론입니다.
Vincent Driessen의 블로그 글에 의해 널리 퍼지기 시작했고 현재는 Git으로 개발할 때 거의 표준과 같이 사용되는 방법론입니다.

GitFlow 구성

• master : 기준이 되는 브랜치로 제품을 배포하는 브랜치입니다.
• develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 병합(Merge)합니다.
• feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합칩니다.
• release : 배포를 위해 master 브랜치로 보내기전에 먼저 **QA(품질검사)**를 하기위한 브랜치입니다.
• hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치입니다.

master와 develop가 중요한 매인 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치라고 보시면 됩니다.

GitFlow 모델

1. master브랜치에서 시작합니다.
2. 동일한 브랜치를 develop에도 생성합니다. 개발자들은 이 develop 브랜치에서 개발을 진행합니다.
3. 개발을 진행하다가 회원가입, 장바구니 등의 기능 구현이 필요할 경우 A개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 회원가입 기능을 구현하고 B개발자도 develop 브랜치에서 feature 브랜치를 하나 생성해서 장바구니 기능을 구현합니다.
4. 완료된 feature 브랜치는 검토를 거쳐 다시 develop 브랜치에 합칩니다. (Merge)
5. 이제 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 만듭니다. 그리고 QA(품질검사)를 하면서 보완점을 보완하고 버그를 픽스합니다.
6. 모든 것이 완료되면 이제 release 브랜치를 master 브랜치와 develop 브랜치로 보냅니다. master 브랜치에서 버전추가를 위해 태그를 하나 생성하고 배포를 합니다.
7. 배포를 했는데 미처 발견하지 못한 버그가 있을 경우 hotfix 브랜치를 만들어 긴급 수정 후 태그를 생성하고 바로 수정 배포를 합니다.

GitFlow 자세히 알아보기

branch를 merge 할 때는 항상 --no-ff 옵션을 붙여서 branch에 대한 기록이 사라지는 것을 방지하는 것을 원칙으로 합니다.

develop / master

GitFlow는 develop과 master를 나누는 아이디어가 가장 핵심입니다. 따라서 다른 version 관리 방식과의 차별점이기도 합니다.
나머지 feature, release, hotfix 브랜치들은 develop과 master를 나눈 결정에 다라 자연스럽게 발생하게 됩니다.

• master 는 현재 production의 상태와 일치하는 branch 입니다.
• develop 은 현재 개발이 완료된 상태와 일치하는 branch 입니다.
  • 개발이 완료되었다는 것은 다음 릴리즈를 위해 언제든 배포될 수 있는 상태를 말합니다.
• 이 두 branch 는 (프로젝트가 존재하는 한) 영원히 존재합니다.

feature branches

• 문제상황
  1. develop 에서 새로운 feature 작업을 commit 합니다.
  2. origin/develop 에 push를 합니다.
  3. 그 사이에 누군가 commit을 한 사람이 있다면 충돌이 일어납니다.

• 목적
  develop 을 현재 개발 완료 상태와 일치시키면서도 다른 동료와 conflict가 생기지 않도록 작업 하기 위해 feature branches를 이용합니다.
• 작업
  1. develop 에서 feature branch 를 생성해서 새로운 작업을 시작합니다.
     • ex. feature/ISSUE-101
  2. feature branch 에서 작업이 끝나면 feature branch를 최신 develop 에 merge 합니다.
  3. conflict 없이 깔끔하게 해결 됩니다.

release branches

• 문제상황
  1. 배포를 준비합니다.
  2. develop에서 ChangeLog.md도 작성하고 version명도 바꿔주고 배포를 위한 몇몇 작업을 처리해줍니다.
  3. develop을 master에 merge하고 배포하지만 release의 feature가 의도치않게 함께 배포 되는 상황입니다.

• 목적
  release 준비를 시작한 뒤에 develop에 merge 되는 다음 release feature 로부터 안전한 release 를 하기 위해 release branches를 이용합니다.
• 작업
  1. develop 에서 release branch를 생성해서 새로운 작업을 시작합니다.
     • ex. release/1.1.0
  2. release branch에서 version bumping, minor bug fix 등의 작업이 끝나면 release branch를 최신 develop 과 master 에 각각 merge 합니다.
     • develop: release branch에서의 bug fix 등 수정 사항들이 develop 에도 반영되어야 하기 때문
     • master: 새 version을 release 하기 위해
  3. master 의 merge commit에 version을 tag로 붙여줍니다.
     • ex. 1.1.0
  4. 이제 release branch를 생성한 후에 develop 에 어떤 작업이 merge되어도 안전하게 배포가 가능합니다.

hotfix branches

• 문제상황
  1. production 에서 문제가 발견되었습니다.
  2. develop에서 수정해서 올리려 하는데 이미 다음 release의 feature들이 commit된 상황입니다.

• 목적
  develop 과 독립적으로 production에서 발생한 문제를 master 에서 처리하기 위해 hotfix branches를 이용합니다.
• 작업
  1. master 에서 hotfix branch를 생성해서 bug fix, version bumping등의 작업들을 진행합니다.
     • ex. hotfix/1.1.1
  2. hotfix branch에서 작업이 끝나면 hotfix branch를 최신 develop 과 master 에 각각 merge합니다.
     • develop: hotfix branch에서의 bug fix 등 수정 사항들이 develop 에도 반영되어야 하기 때문
     • master: 버그가 수정된 새 version을 release 하기 위해
  3. master 의 merge commit에 version을 tag로 붙여줍니다.
     • ex. 1.1.1
  4. 이제 develop 의 작업과 상관없이 master 에 bugfix를 배포가 가능합니다.

Reference

https://nvie.com/posts/a-successful-git-branching-model/

https://blog.gangnamunni.com/post/understanding_git_flow/

https://ux.stories.pe.kr/183