Branch 전략

git flow(참고링크), github flow(참고링크), gitlab flow

github flow + develop

• 정의

  1. 마스터 브랜치는 배포 가능한 브랜치이다.
  2. 새로운 작업을 하기 위해 해당 작업을 master로부터 브랜치를 생성한다. (i.e new-oauth2)
  3. 로컬 브랜치에서 커밋 후 정기적으로 origin 에 push한다.
  4. 코드 리뷰를 받거나 머지할 준비가 되면 p-r을 연다.
  5. 리뷰를 받고 master 로 푸쉬되면, 즉시 배포한다.

  GIt-flow, GitLab-flow, Github-flow란?

  <aside> 💡 Git flow를 선택하지 않은 이유

  • git flow는 개발과 테스트, 릴리즈 등을 동시에 진행하면서 서비스를 관리하기 위한 브랜치 전략이다.
  • 현재 서비스가 배포되어 있지 않고 별도의 팀(예를 들어 QA팀)에서 테스트를 진행하거나 하지 않는데, git flow를 써야할까? </aside>

  <aside> 💡 그렇다면 Github Flow를 사용하는 이유는?

  • 브랜치 전략이 단순하기 때문에 효율성이 높을 거라고 판단했다.
  • Main 브랜치를 깔끔하게 유지해야하는 전략이기 때문에 PR을 날릴 때마다 코드 리뷰가 강제할 수 있다.
  • 해당 프로젝트가 서비스로 정착되고나서 git flow를 적용해도 괜찮을 거라고 생각한다. </aside>

• Main브랜치를 정말 깔끔하게 유지해야한다.

  • PR, 코드리뷰 신경쓰기
  • ESLint로 console.log() 적으면 경고뜨게 만들기

• front와 back

  • 이슈를 백엔드 프론트엔드 나눠서 상세하게 작성한다.
  • 이슈 넘버를 브랜치명 앞에 붙임으로써 구분할 수 있다.

• branch 구조

  • main - 배포용. 최상단 브랜치
  • develop - 개발 통합용
  • feature/* - 개발 피쳐별 브랜치
  • fix/* - 버그 수정 피쳐별 브랜치
  • refactor/* - 리팩토링 브랜치

  

1. develop → [feature | fix | refactor]/${issueNumber}-${기능이름} → pr → develop
2. main -> develop -> main

ex) feature/50-login, fix/51-login-error

Branch 네이밍 컨벤션

• (feature|fix|refactor)/<Issue#>-<Name>
• 이슈나눌 때 백엔드, 프론트 나눠서 이슈를 작성해야 한다.
• 이슈와 관련지어 영어로 네이밍한다.