Git flow

[출처] : https://nvie.com/posts/a-successful-git-branching-model/ [번역] : https://dogfeet.github.io/articles/2011/a-successful-git-branching-model.html [참고] : https://techblog.woowahan.com/2553/

Branch

Branch convention

<aside> 💡 관련 기능 키워드 작성은 camel case를 사용한다.

</aside>

#feat branch
<백/프>-<관련 기능 키워드>

# 예시
# fe-campaign
# be-user
# docs

# worker branch
<feat branch name>-<관련 기능>

# 예시
# be-user-socialApi
# be-user-logIn
# fe-user-commonSignUp
# fe-campaign-campaignWrite

• 기존의 <타입>:<이슈번호>에서 feat branch / work branch 로 브랜치 컨벤션 변경한 이유
  • 가독성이 떨어진다.
  • 기존의 <타입>:<이슈번호>규칙을 MR Convention으로 이전
  • dev 브랜치에는 완성되고 적용하기로 결정된 기능만 merge 되어야한다.
    • JIRA Epic, Story를 상세하게 쪼개서 구현하기 때문에 dev 브랜치가 온전하게 작동하지 않는 문제 발생
• work branch는 feat branch에서 분기한다.
• 예시

Branch 종류

• 주요 브랜치
  • master
    • 서비스 중인 최종 버전
  • dev
    • 배포 준비 브랜치
    • 배포 준비가 될 경우에 release 브랜치를 분기한다.
• 보조 브랜치

  • be/fe-*

    갈라져 나온 브랜치 : dev merge할 브랜치 : dev 브랜치 이름 규칙 : feat-{기능분류}

    • 브랜치 이름 규칙에 대해서 고민이 있었다. JIRA의 에픽단위로 가기에는 기능이 너무 세분화되어있다. 서비스에 추가되는 기능의 단위는 회원 서비스, 캠페인 서비스 단위이지 회원 가입, 로그인 단위는 아니다. 그렇기 때문에 기능 분류를 Epic 보다 한 단계 더 크게 잡아줘야한다.
    • 해당 기능이 전부 완성된다면 merge를 진행한다.

  • release-*

    갈라져 나온 브랜치 : dev merge할 브랜치 : dev, master 브랜치 이름 규칙 : release-{버전명}

    • release는 배포를 준비하는 브랜치이다. 배포하는데 필요한 버전 넘버, 빌드 일정등의 메타데이터 준비하고 사소한 버그를 잡는다.
    • dev 브랜치가 배포될 수 있는 상태가 되었을 때 release 브랜치로 분기해야한다.
    • 만약 이번 배포에 포함되지 않을 기능은 release 브랜치 분기 전 까지 merge를 하지 않는다.
    • release 브랜치를 생성하는 것은 버전 넘버를 새로 부여하는 것을 의미한다.
    • 해당 기능이 전부 완성된다면 merge를 진행한다.
    • 배포 과정에서 발생한 버그는 release 브랜치에서 해결하며 추가되는 기능은 dev 브랜치에 merge하고 다음 배포에 포함시킨다.

  • hotfix-*

    갈라져 나온 브랜치 : master merge할 브랜치 : master, dev 브랜치 이름 규칙 : hotfix-{현재 버전 + 추가버전} ex) 1.2.1

    • 버그를 수정했다면 dev 브랜치에도 merge해줘야지 다음 배포때 수정이 포함되어 배포된다.

MR Conevention

MR : Merge Request == Pull Request == PR == MR

<타입>:<이슈번호> <기능명>
--------------------------
[예시]
feat:S06P22B105-22 백엔드 프로젝트 초기설정
fix:S06P22B105-59 Swagger 작동 안되는 문제 수정

• 타입 리스트

1. Merge Request 생성