FE‐브랜치 전략

FE 브랜치 전략

저희는 GitHub-Flow를 사용합니다

Git-Flow 대신 GitHub-Flow를 사용한 이유

1. 단순한 브랜치 구조 및 편리한 CI/CD

   GitHub-Flow를 따르는 것이 에자일 성격에 보다 부합하다고 생각했습니다

   Git-Flow 는 develop → release → main 의 단계로 PR을 통해 병합이 되어야 하지만 GitHub Flow 는 main브랜치에만 바로 병합이 되면 배포가 가능합니다.

   그러므로 보다 단순한 브랜치 구현을 가져가면서 CI/CD 역시 간편하게 사용 할 수 있다 생각합니다.

2. 웹 앱 특성에 부합

   프론트엔드에서 개발하는 웹 어플리케이션 특성상 버전을 분리해서 개발하지 않기 때문에(=단일 버전)

   굳이 버전 관리에 보다 특화된 Git-Flow를 가져갈 이유가 없다고 판단했습니다

참고1 , 참고2

---

브랜치 명

Github-Flow는 브랜치 이름만으로 어느 기능이 포함 됐는지 알 수 있도록 최대한 자세히 적어야 합니다

그러므로 추상적인 부분을 덜어내기 위해 브랜치가 어느 기능을 의미하는지 prefix와 함께 kebab-case 형태로 작성 합니다

prefix 종류들

타입	설명
feat	새 기능 구현
fix	버그 수정
docs	문서/주석 관련 작업
refactor	리팩토링
test	테스트 관련 작업
style	디자인 관련 작업
chore	기타 작업

chore-ESLint,prettier-setting : 프로젝트 ESLint,prettier 세팅

feat-problem-menu-buttons : 문제 페이지 메뉴 버튼들 구현

style-login-input : 로그인 페이지 인풋창 스타일링

docs-readme : README.md 수정