rnjstjdgh
commented
2 years ago 이런 Convention 을 정하는 이유는 협업을 잘 하기 위함임을 잊지 말것.
- 이슈, PR, Commit 모두 의도가 명확하고 리뷰어가 이해하기 쉽도록 작성해야 합니다.
- 이러한 목적을 위해 이슈, PR, Commit 을 적절하게 분해하고
- 명확한 메시지를 남길것.
기준이 자주 변하더라도 항상 우리만의 기준은 있어야 합니다.
- 아래 3가지 사항에 대한 기준을 정하는 것은 중요하다고 생각합니다.
- 이슈(브랜치)를 어느 수준으로 나눌지
- PR 을 어느 수준으로 나눌지
- Commit 을 어느 수준으로 나눌지
- 지금은 우리가 경험이 부족해 확고한 기준은 없지만 앞으로 경험하고 수정하면서 기준을 찾아가야 할 것 같습니다.
- 우선은
- 기능 단위[
ex> 글 목록 페이징, 글 작성, 이미지 업&다운로드......] 로 이슈(브랜치)를 분리 후 - 작은 단위라도 유의미한 기능 구현이 끝났다면 Commit
- 이슈에 해당하는 기능 구현이 끝났거나 어느정도 완성 되어서 통합 테스트(UI + SERVER) 가 필요하다고 판단되는 수준에서 PR
- 해당 이슈가 완벽하게 해결 되어 더는 문제가 되지 않을 때 이슈를 close 하고 브랜치를 삭제
- 기능 단위[
프로젝트가 잘 진행됨에 따라 더 나은 협업을 위해 브랜치 관리 방법이 필요하다고 판단하여 브랜치 관리 방법을 마련해봤습니다.
변경사항
dev, dev_frontend, dev_backend 기존 브랜치의 직접적인 푸시를 막습니다. 해당 브랜치에 기여하기 위해선 앞으로는 이슈 번호로 브랜치를 만든 후에 PR을 보내주세요.
브랜치 이름 규칙
backend: BACK-이슈번호 frontend: FRONT-이슈번호 ex) 이슈번호가 20번이면 BACK-020
브랜치 관리
main (프로덕트) - dev (stage, 2명 이상 PR 승인 필요) - dev_frontend, dev_backend (develop, 1명 이상 PR 승인 필요) - 기타 이슈 브랜치