형상 관리 규칙

형상관리 규칙

• 관리
  • 형상관리 툴 사내 gitlab 사용
  • 1일 1회 이상 Push(기능 개발 건 마다 Commit 후 퇴근 전 Push)
  • 계정 공유 X
  • Master 브랜치는 별도의 관리자가 병합
  • Develop MR(Merge Request) 기준 코드리뷰 실시
• Branch
  • Branch 종류
    1. Master
    A. 배포 시점마다 Tag 부여 {version}
    1. Develop
    2. Feature
    A. feature/{gitlab아이디}/{브랜치생성일자}
    1. Release
    A. Release/{version}
    1. Hotfix
    A. Hotfix/{Issue}/{Issue number}_{shot description}
• Branch 설명
  1. Master
  출시 할 수 있는 브랜치
  1. Develop
  다음 출시 버전을 개발하는 브랜치이 브랜치를 기반으로 모든 기능개발/버그수정 브랜치를 Merge하고 배포 가능이면 master 브랜치에 Merge
  1. Feature (ex. feature/heejin/20220329)
  기능을 개발하는 브랜치개발이 완료되면 Develop 브랜치로 병합3-2. 새로운 기능에 대한 개발 수행
• 3-3. 개발이 완료되면 ‘develop’와 병합
• 3-1. ‘develop’ 브랜치에서 새로운 기능에 대한 feature 브랜치를 분기
• 새로운 기능 개발 및 버그 수정이 필요할 때마다 Develop 브랜치로부터 분기
• Master에서 분기되어 기능 개발을 위한 브랜치들을 병합하기 위해 사용
• 최종 배포 이력 관리하기 위한 최상위 브랜치

1. Release (ex. release/1.0)

출시 버전을 준비하는 브랜치

Develop 브랜치에서 배포할 수 있는 시점에 Release 브랜치 생성

그 이후 테스트, 버그수정, 문서추가 등 Release 출시 직전에 하는 단계들을 진행

버그 수정이 있다면 수정 후 Develop에도 병합

모든 Release 직전 단계를 완료하면 Master 브랜치로 병합하고 Tag를 부여

1. Hotfix (ex. Hotfix/Issue/001_UI)

출시 버전에서 발생한 버그를 수정하는 브랜치

출시 버전에서 버그가 발생하면 Master에서 분기하고 수정 후 병합

Develop에도 병합