Git Branch 전략

4단계의 Slim Git Flow 전략

구성 요소

hotfix

• main에서의 문제를 수정하는 브랜치

• 수정 후 main으로 merge후 삭제

main

• dev에서 머지가 이루어지는 브랜치

• 직접 커밋 불가능

• 문제가 생긴 경우 hotfix 브랜치를 파서 진행

dev(default)

• feature에서 머지가 이루어지는 브랜치

• 직접 커밋 불가능

• 문제가 생긴 경우 feature/Fix… 이런 식으로 브랜치를 파서 진행
• ex) feature/FixLogin

feature

• 기능 개발이 이루어지는 브랜치

• PR후 브랜치 삭제(local은 알아서)

브랜치 네이밍

feature/이슈번호/페이지단위 or 컴포넌트(이건 유동적으로 가능)

ex)
feature/#13/Navbar
feature/#12/Button

hotfix/이슈번호

ex)
hotfix/#100

핵심 규칙

• rebase를 지양하고 merge방식을 사용합니다.
• rebase를 통해 commit history를 관리하고 충돌을 일일이 해결하는데 시간을 들이기 보다는 기능 개발에 더 집중하는 것을 목표로 합니다.
• merge방식의 최대 단점인 commit history가 더러워 지는 문제를 최대한 보완하기 위해 반드시 feature 브랜치가 아닌 dev 브랜치를 merge합니다.

• release 에 머지하는 경우를 제외 하고는 squash merge가 아닌 일반 merge를 사용합니다.

• 현재 올라간 PR을 반드시 끌어와 기능 개발을 이어가야 하는 경우면 팀원들과 의논해 빠르게 merge를 하고 pull을 합니다.

• pr 커맨트