컨벤션

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: 테스트 설명

**8. 빌드 업무/패키지 매니저 수정:📦chore: 패키지 변경사항 설명

---

3. PR Template

commit 메세지가 적절한지 확인하기
적절한 브랜치로 요청했는지 확인하기
PR이 승인되면 해당 브랜치 삭제하기

테스크

---

• 이슈에 대한 작업이라면 PR과 이슈 연결
• 작업 이유와 작업에 대해 고민했던 점 작성하기

작업 내용

---

이번 테스크에서 작업한 내용을 적어주세요.

스크린 샷(선택 사항)

---

동작 화면 첨부