Threadly 프로젝트는 안정적인 배포를 위해 master-develop-작업 브랜치 구조를 따른다.

운영 서버는 master 브랜치와 연결되어 있으며, 모든 개발은 develop 브랜치를 중심으로 진행한다.

• master: 운영 서버와 연결된 메인 브랜치
• develop: 개발 통합 브랜치(모든 기능이 merge 되는 브랜치)
• 작업 브랜치: 항상 develop 브랜치에서 분기하여 생성한다.

<prefix>/<Jira Issue Key>-<작업 내용>

예시

feature/TLY-108-kafka-mail-publisher

• feature: 새로운 기능 추가 / 일부 코드 추가
• fix: 버그 수정
• refactor: 코드 리패토링(동작은 동일, 구조 개선)
• style: 코드 의미에 영향 없는 변경(포맷팅, 주석, 네이밍 등)
• chore: 빌드 설정, CI/CD 설정 등
• docs: 문서 추가 / 수정(README, 위키 등)

예시

feature/TLY-94-user-profile
refactor/TLY-61-seperate-post-controller`
docs/TLY-113-troubleshooting

• develop에서 작업 브랜치를 분기

• 작업 브랜치에서 기능 개발 또는 버그 수정

• develop <- 작업 브랜치로 PR 생성

• CI 테스트 통과 후 Merge 가능
• develop에 Merge

• master <- develop으로 PR 생성 및 merge

• master 브랜치는 운영 환경과 연결되어 있다.
• 모든 개발은 브랜치는 develop 브랜치에서 분기한다.
• 브랜치 네이밍은 <prefix>/<Jira Issue Code>-<작업 내용 규칙>을 따른다
• PR이 생성되면 CI 테스트가 통과한 경우 Merge한다.

• CI CD 동작 프로세스