Branch Rule

git flow vs github flow

• git flow 결정(main과 dev를 구분하기 위해)
  • git flow를 사용하지만 feature 브랜치 세분화
• github flow는 main만 두고 바로 머지하는 구조라서 우리와 안맞음 → 실 서비스 운영에 더 적합

⇒ 현재는 빠른 개발을 위해 main 대신 dev에 머지되면 바로 배포되는 github flow를 사용 중입니다.
(2023-11-28 01:33 기준)

Feature 브랜치 세분화

feature: origin / upstream

개인 포크 레포에 저장(upstream)

어짜피 개인 레포에만 해당 브랜치 존재 → dev에 PR 요청

현재까지의 과제 방식

장점 : 로그가 좀 깔끔해짐 → 실수해도 PR 안하면 크게 문제없음

메인 레포에 저장(origin)

메인 레포에서 피처 브랜치 만들어서 dev에 PR 요청(삭제ox)

장점: 실제로 브랜치가 보여서 누가 뭐하고 있는지 보임

git checkout -b bfm-100_login_layout –track upstream/feature-user

브랜치명 정하기

• ex) Feat-jeongseok-24 : '/'를 통해 폴더 구조를 만들고자 제외

• ex) Feat/#24 : 어떤 파트의 작업인지 확인하기 어려우므로 제외

• ex) Feat/KCH/#24 : 한명이 작업하지 않을 수 있어서 제외

• ex) Config/jeongseok/install-axios : 작업에 따라 브랜치명이 길어지므로 제외

• ex) Feat/install-axios : 작업에 따라 브랜치명이 길어지므로 제외

• ex) Feat/FE/#24 : 어떤 작업 / 어느 분야 / 어떤 이슈 를 표기할 수 있어 해당 방식으로 최종 선택

Git Flow의 기본 브랜치 명

• master : 제품으로 출시될 수 있는 브랜치
• dev : 다음 출시 버전을 개발하는 브랜치
• feature : 기능을 개발하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치 → 현재 단계에서 필요 없다고 생각함.
  • 웹은 CI/CD 구축되면 자동 배포되는 구조라서 release 개념이 사라짐
• hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
• config : 라이브러리 설치 등의 세팅 값을 위한 브랜치

⇒ {접두사}/{분야}/{#issue} (ex. Feature/FE/#24)

Feature 브랜치 세분화

접두사

브랜치 접두사	의미
Feature	기능추가(테스트코드 포함), CSS 등 사용자 UI 디자인 변경
Fix	버그 수정
Refactor	기능 변경 없이 코드수정된 경우
Test	테스트 코드만 추가하거나 수정할 때
Config	환경설정 및 라이브러리 설정(패키지 매니저 수정)
Chore	파일 혹은 폴더명 수정하거나 옮기는 경우 그 외 기타 수정(코드 포맷팅), 오타 정정
Docs	문서 작성 및 수정(README 수정)

분야

BE or FE or WE

원본 링크

Branch Rule - Notion

Last Updated: 2023.12.12. 14:51