more information : https://hai.seoultech.ac.kr/

• 다음 Coding Rule 하위 내용을 각 프로젝트(Repository) 마다 복사하여 작업해주세요.
• 본 Coding Rule은 각 프로젝트 사정에 맞게 수정하여 사용할 수 있습니다.

문의 : DY-76

제정 23.2 | 개정 23.4 | 개정 23.8 | 개정 26.7

• 작업, 유지보수의 편의성 증진과 효율적이고 강건한 애플리케이션 개발을 위해 Coding Rule을 제정한다.

• Class = PascalCase
• variable, function, method = camelCase
• constant variable = UPPER_CASE
• filename, folder = kebab-case

• {major}.{minor}.{patch}
• major: 이전 버전과 호환이 안 되는 변경이 있을 시 업데이트.
• minor: 이전 버전과 호환되는 기능 추가가 있을 시 업데이트.
• patch: 이전 버전의 버그를 수정했을 시 업데이트.

• 프리알파(pre-Alpha) : 이 단계는 실제 개발 이전 단계의 모든 버전을 칭하며, 보통 프로토타입까지를 의미한다.
• 알파(Alpha) : 프로토 타입 이후 실제 테스트를 시작하는 단계부터 어느정도 기능이 구현된 단계를 의미하며, 이 단계에서는 일부 기능 별로 테스트를 수행한다.
• 베타(Beta) : 알파 이후부터 소프트웨어 기능의 완성 전 버전까지를 의미한다.
• RC(Release Candidates) : 최종 릴리즈 혹은 출시후보를 의미한다.

• master(main, origin etc...)
  • master branch는 Repository 생성시 자동으로 생성된다.
  • 일반적으로 완성된 최신 작업물을 merge하는 곳으로 사용한다.
  • release or hotfix에서 PR을 받아 책임 혹은 담당 개발자가 검토 후 merge한다.
• develop
  • develop branch는 애플리케이션의 개발을 진행할 때 사용한다.
  • 어느정도 작업이 완료된 경우, release branch로 PR을 보내고 다음 기능 개발을 위한 feature branch를 분기한다.

• feature
  • feature branch는 애플리케이션의 기능을 제작할 때 사용한다.
  • 일반적으로 feature/기능이름 형식을 추천한다. ex) feature/login 등
  • 작업이 완료된 경우, develop branch로 PR을 보내고 정상적으로 merge된 경우 제거한다.
• release
  • release branch는 배포버전의 애플리케이션을 관리할 때 사용한다.
  • 일반적으로 release/목표Version 형식을 추천한다. ex) release/2.0 등
  • 특정 수준까지 작업이 완료된 develop branch에서 배포가 필요할 때, release branch를 생성하고 bugfix 후 master branch로 merge한다.
  • 정상적으로 배포가 확인되면 이후 제거한다.
• hotfix
  • hotfix branch는 배포된 애플리케이션의 오류를 긴급 수정할 때 사용한다.
  • 일반적으로 hotfix/Version.num 형식을 추천한다. ex) hotfix/2.0.1 등
  • master branch에서 분기하여 작업을 진행하고, 완료된 경우 다시 master branch로 merge한다.
  • 오류 수정이 완료되면 이후 제거한다.