Github Branch 전략

소규모 브랜치 전략은 master / developer 만 유지하고 간결하게 운영을 하려고 한다.

브랜치가 많을 수도록 관리 포인트가 많으며, 브랜치별 Merge 작업 또한 빈번한 작업이 될 수 밖에 없다.

그러므로 심플한 전략과 단위 프로젝트에 적합한 방안으로 구성한다.

1. 브랜치 종류

Branch	설명	비고
master	master 브랜치로 최종 운영서버에 릴리지 되는 브랜치이며, 기본 브랜치이다. Tag 작업으로 운영에 배포 할 버젼을 지정한다.	담당자가 Merge 작업
stage	QA 서버용 브랜치로 develop 브랜치에서 merge된 정보를 활용하여 QA서버에 반영하기 위한 브랜치로 사용된다.	담당자가 Merge 작업
develop	개발을 위한 용도로 개발자는 해당 브랜치에서면 하위 브랜치를 만들어서 사용을 하면된다.	개발자가 Merge 작업
feature	feture명은 개발자가 임의로 정하며, develop의 Merge 작업 또한 개발자가 담당한다.

 

·         운영서버의 반영은 Tag 로 처리한다.

2. Feature 브랜치 ID

·         일반적으로는 JIRA의 Task ID를 기준으로 한다.

·         만약 JIRA에 등록되지 않은 브랜치를 만들경우는 master 및 stage, develop 과 같이 사전에 정의된 이름을 사용하지 말것.

3. Commit Message 규칙

·         [JIRA 타스크ID] + 업무메세지 로 정의한다.