컨벤션

github branch strategy - GitHub Flow

결정 과정

Git Flow vs GitHub Flow vs TBD(Trunk Based Development)

Git Flow

1. 각 용도에 맞게 main(master), develop, feature, release, hotfix 브랜치를 분리해서 사용
2. 명확한 릴리즈 기간과 주기적인 버전이 정해진 프로덕트를 개발하는 환경에 적합
3. 릴리즈 버전 관리를 위한 release 브랜치를 따로 관리하기 때문에, 특정 버전에 대한 유지보수 기간이 길고, 여러 버전을 동시에 관리해야 할 필요가 있을때 유용함
   관리 할 브랜치가 많아지고 해당 프로젝트가 이정도의 규모가 아니라 탈락

⭐GitHub Flow⭐

1. Git Flow가 Github에서 사용하기에는 복잡하다고 나온 브랜치 전략
2. hotfix 브랜치나 feature 브랜치를 구분하지 않음
3. 수시로 배포가 일어나며, CI와 배포가 자동화되어있는 프로젝트에 유용
   Git Flow만큼 복잡하지 않으면서 TBD처럼 너무 간단하지 않아서 선정

TBD

1. 기본적으로 Trunk/Main 브랜치 하나만 사용
2. 신규 피쳐의 경우 main에 커밋하거나, 수일 내로 머지 할 브랜치를 생성
3. PR을 생성하지 않음
   PR을 생성한다고 하면 GitHub Flow와 다를게 없고 없앤다고 하면 추적이 힘들어져 탈락

---

1. branch Name Convention

1. 기능 추가: feature/기능명

• ex) feature/login, feature/add-product

2. 버그 수정: fix/버그명

• ex) fix/login-err

3. 리팩토링:refactor/리팩토링명

• ex) refactor/login-ui

4. 문서:docs/문서명

• ex) docs/readme

---

2. commit Convention

1. 기능 추가:✨feat:기능 설명

2. 버그 수정:🐛fix: 버그 설명

3. 리팩토링:♻️refactor: 리팩토링 설명

4. 성능 개선:⚡️perf: 성능 개선 설명

5. 스타일 수정:💄style: 스타일 수정 설명

6. 문서 추가/수정:📝docs: 문서 설명

7. 테스트 추가/수정:✅test: 테스트 설명

3. PR Convention

추가예정