📖 브랜치 및 커밋 컨벤션

📖 브랜치 컨벤션

기본적으로 GitFlow 브랜칭 전략을 사용합니다.
새로운 기능 또는 버그에 대한 작업시 반드시 ISSUE 를 먼저 생성 후, 해당 이슈넘버를 태그해 작업합니다.

feature : 새로운 기능을 개발하는 브랜치입니다. feature#0, feat/#0 과 같이 이슈넘버를 사용해 하위 브랜치를 생성합니다.
fix : 기능에 버그가 있을때 버그를 수정하는 브랜치입니다. fix#0, fix/#0 과 같이 이슈넘버를 사용해 하위 브랜치를 생성합니다.
develop : 다음 출시 버전을 개발하는 브랜치입니다.
release : 이번 출시 버전을 준비하는 브랜치입니다.

브랜치의 병합은 Recursive Merge 방식을 사용해 병합합니다.

리뷰어들은 병합(Merge) 시 아래와 같이 커밋 메시지를 작성해주세요.

예를 들어, 지금 제가 병합을 위해 PR 을 날린 상태입니다.

리뷰어는 해당 PR을 검토 후 Master branch(우리 프로젝트에서는 Develop) 로 병합을 시킬 텐데, 아래와 같은 화면이 기본 화면입니다.

이미 PR을 올릴 시점에 해당 기능에 대한 설명이 담긴 커밋들이 쌓여 있을테니 해당 란에 해당 PR에 대한 설명을 재차 작성하실 필요 없습니다.

의도는 좋으나 나중에 커밋 히스토리에서 중복 커밋 처럼 보이고, 오히려 가독성이 떨어집니다.. ㅠㅠ

위 예시와 같이 Merge: Feature ➞ Develop 같은 직관적인 메시지를 작성해주세요.

'기능 브랜치에서 개발(Master) 브랜치로 병합했다.' 누가봐도 한눈에 알아 볼 수 있게 됩니다!

아래는 병합 후 커밋 히스토리 사진입니다.

마지막으로, 기능 개발이 많아질 수록 기능 개발에 사용한 브랜치가 계속 쌓이게 됩니다.

때문에 Merge 후 Pull Request 창 하단에서 해당 브랜치를 삭제 해주세요!