브랜치 전략

<aside> 💡 main ↔ develop ↔ feature

</aside>

• main: 코드리뷰 끝난 코드만, 스프린트 마지막

• develop : 모든 개발 변경 사항 저장 (배포 전)

• 개발 시 : feature/이슈번호-chatting

• 개인 레포 개발 완료 후

  • pull request feature/123-chatting → develop

• 브랜치명 예시 feature/123-chatting style/ fix/ hotfix/

• 일정 주기로 develop 개발 내용을 main 브랜치에 반영한다.

이슈당 브랜치 하나

• 참고 자료
• 이슈 생성 후 브랜치 생성

github repository 개발 순서

<aside> 💡 -

1. 깃허브 slam-talk-frontend 리포지토리를 local에 clone

   (백엔드 - fork)

2. 기능 명세서에 해당하는 기능 혹은 개발할 사항에 대해 이슈 생성

   마일스톤, 라벨링 등 태그 명시

3. 내가 개발할 기능에 해당하는 브랜치 생성

   • feature/이슈번호-terminal
   • feature/이슈번호-filetree

4. 개발 후 Pull Request → develop

   #이슈번호 명시로 이슈와 PR 연결하기

5. 코드리뷰

   • 24시간 안에 확인하기
   • 한 명 이상이 확인하면 merge 가능
   • 요청시 모여서 코드리뷰

6. develop 브랜치에 merge, 이슈 Closed

7. 로컬 개발 branch에 업데이트 사항 반영(pull, merge) </aside>