1️⃣ [11.15] Week2 Day2 회의록

1. 브랜치 전략에 대해서

— 이슈 라벨을 지정하면서 배포 와 릴리즈 구분에 대해서 의문을 가짐

• 둘을 나눈 의도는 main 브랜치에 올리는 코드와 dev 브랜치에 올리는 코드의 구분이 필요하다고 생각했음
• dev 브랜치에 올리는 코드는 매일 개발 내용을 확인할 수 있는 용도로 사용하고자 함
• main 브랜치에 올리는 코드는 릴리즈에 해당하여 매주 데모 데이 전에 올리는 버전이라고 생각

⇒ 하지만 현재 dev 서버와 실제 릴리즈 서버가 구분되어 있지 않음

⇒ 기존 브랜치 전략을 사용할 때에는 암묵적으로 2개의 서버를 사용한다는 것을 전제로 하고 생각했음

⇒ 따라서 하나의 서버를 사용한다는 상황에 알맞게 브랜치 전략을 수정하기로 함

---

결론

• main : release 브랜치, 설정한 버전 feature까지 개발이 완료되면 PR, Merge 되는 브랜치, dev → main

• dev : CD 가 적용되는 개발용 브랜치, feat → dev

  → 실제 웹 사이트가 배포되는 브랜치

• fix : dev 브랜치(서버)에 배포가 되고, 문제가 생겼을때 사용하는 브랜치

• feat/[feature-name]

  • 등록된 이슈를 기반으로 브랜치 생성
  • 백로그에 해당 이슈를 작업 중인 브랜치 이름을 명시