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 커맨트