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: origin / upstream

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

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

현재까지의 과제 방식

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

메인 레포에 저장(origin)

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

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

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

Feature 브랜치 세분화

브랜치명 정하기

Git Flow의 기본 브랜치 명

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

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