Branching strategy,

츠누봇 관리자 페이지 프로젝트의 브랜치 전략은 하기와 같습니다. 일반적으로 git flow 전략을 채택하지만, release 브랜치의 필요성을 느끼지 못하여 사용하지 않습니다.

main - 안정적인 상태의 배포가 진행된 브랜치 develop - 기획자 & 프로젝트 오너 가 배포전에 최종적으로 production 환경에서 테스트 하는 브랜치 feat - 개발자가 기능을 구현하는 브랜치 fix - 개발자가 기능을 수정하는 브랜치 (develop 에서 오류가 있다면) hotfix - 급한 오류를 수정해야 할 경우 사용하는 브랜치(main 에서 오류가 있다면)

개발자는 자신이 맡은 기능을 feat 브랜치에서 수정 후 develop 브랜치로 Pull Request를 생성합니다. 그 후 자동화된 테스트를 이용하여 컴퓨터를 활용해 코드의 검증을 진행한 후 문제가 없다면 리뷰어들이 코드 스멜을 검증합니다. 그 후 적합한 기능을 수행한 코드라면 develop브랜치로 merge하는 과정을 거칩니다.