Issue단위 브랜치 전략

목적

branch 네이밍을 통해서 작업의 의도를 갖게 하는 것은 한계가 있습니다. Github Issue는 각각의 유니크한 값인 Issue Number를 갖습니다.  고유한 Issue Number를 기반으로 branch를 이름을 작성하여 해당 branch의 명확한 작업 의도를 파악할 수 있게 노력했습니다.

브랜치 전략과 관련된 자세한 내용은 Connect-wiki : Git repo관리에 작성했습니다. (저희가 시도했던 3가지 브랜치 전략에 관한 고민을 정리했습니다)

브랜치 전략 및 레포지로리 관리

front, back이라는 파트별 브랜치를 없애고 develop브랜치에서 바로 feature브랜치를 생성한다.

fork를 하지 말고 공통 레포지로리를 origin으로 사용

.
└── main (origin)
      ├─ deploy # 배포 브랜치
      └─ develop
            ├── FE/#12-login_page
            ├── FE/
            ├── BE/#11-something
            └── BE/

# 브랜치 네이밍: 
# [BE|FE]/<feature>/<#이슈번호>-<세부내용>
# 예시: FE/feature/#12-login_page

feature단위

기능 단위로 feature브랜치를 생성한다.

우리 프로젝트에서는 기능 단위로 이슈를 생성하기 때문에 이슈별로 브랜치를 생성한다.

develop 기능 반영하기

feature작업이 끝나면 pr을 통해 develop에 반영한다.

develop브랜치가 업데이트되면 나머지 팀원들은 작업하던 브랜치 및 개인 로컬에 develop브랜치를 최신화한다.

⚠️ 주의사항

절대 임의로 develop브랜치에 commit하지 않는다. 혹시나 하게 된다면 확실한 방법으로 팀원모두에게 알려야한다.

3-3. deploy브랜치

배포 브랜치입니다.

사용 예시

예시: FE/#235-loading_ui, BE/#130-oauth_github

이후 develop 브랜치에 작업한 featture 브랜치를 merge하는 방식으로 진행했습니다. merge를 진행할 때는 pull request를 활용해 코드 리뷰 및 작업 현황 공유를 하였습니다.