Branch 전략
git flow(참고링크), github flow(참고링크), gitlab flow
github flow + develop
-
정의
- 마스터 브랜치는 배포 가능한 브랜치이다.
- 새로운 작업을 하기 위해 해당 작업을 master로부터 브랜치를 생성한다. (i.e new-oauth2)
- 로컬 브랜치에서 커밋 후 정기적으로 origin 에 push한다.
- 코드 리뷰를 받거나 머지할 준비가 되면 p-r을 연다.
- 리뷰를 받고 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/*
- 리팩토링 브랜치
![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0a7b74ba-19b0-4cc7-a0be-3ca94fae82a6/Untitled.png)
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>
- 이슈나눌 때 백엔드, 프론트 나눠서 이슈를 작성해야 한다.
- 이슈와 관련지어 영어로 네이밍한다.
커밋 타입 |
설명 |
feature |
새 기능 |
refactor |
리팩토링 |
fix |
버그 수정 |