Skip to content

Latest commit

 

History

History
136 lines (101 loc) · 3.82 KB

컨벤션목록.md

File metadata and controls

136 lines (101 loc) · 3.82 KB
Raw

💬 Tooliv의 화목한 협업을 위한 컨벤션 💬

목차


✨ Git

Branch 전략 - Git Flow

  • master
    • 배포할 완성 프로젝트 브랜치
  • develop
    • 개발 완료한 기능(feature 브랜치)을 통합하는 브랜치
  • feature/~~
    • 기능 단위로 개발을 진행하는 브랜치
  • release/~~
    • develop 브랜치를 가져와서 배포 전 최종적으로 확인하고 new version으로 확립하는 브랜치

Commit 컨벤션

🖇️https://udacity.github.io/git-styleguide/ 참고

  • feat: A new feature
    • 새로운 기능
  • fix: A bug fix
    • 버그 수정
  • docs: Changes to documentation
    • 문서 내용
  • style: Formatting, missing semi colons, etc; no code change
    • 미세한 변경 사항
    • 포맷, 세미콜론 수정, Optimize import, Code clean up 등 코드가 아닌 스타일에 관련된 수정
  • refactor: Refactoring production code
    • 코드 리팩토링 (성능 차원)
  • test: Adding tests, refactoring test; no production code change
    • 테스트 코드
  • chore: Updating build tasks, package manager configs, etc; no production code change
    • 빌드 및 설정 파일

Rules
1. feat: ~~~~~~ 형태로 작성한다.
2. 끝에 마침표를 사용하지 않는다.


⭐ Jira

  • Sprint

    • 업무 기간 단위
    • duration 1 week (1주 단위로 진행)

  • Epic

    • 업무의 큰 분류 (카테고리 느낌)
    • 여러 Story들의 집합
    • ex) 회원 관리 기능

  • Story

    • 작은 업무를 구체적으로 명시
    • Epic에 속하는 업무 단위
    • 하나의 Sprint 안에서는 완료할 수 있도록 구성
    • [FE] , [BE], [공통] 라벨링 사용
    • ex) [FE] 로그인 페이지 구현
    • ex) [BE] 로그인 REST API 구축

  • Sub Task

    • Story 하위 작업
    • Story 단위가 클 경우, Story 진행에 있어 필요한 작업을 Sub Task로 등록
    • Sub Task가 모두 완료되어야 Story 완료

  • Assignee

    • 해당 업무의 담당자
    • FE / BE 팀별 회의로 담당자를 배정

  • Estimate

    • 해당 업무의 점수
    • 업무를 진행하는데 걸리는 시간 ( 난이도 유추 가능 )
    • FE / BE 팀별 회의로 해당 업무에 대한 점수를 부여
    • 1주 기간 Sprint → 인원당 최대 40 포인트

  • Release

    • 각 Sprint별 new version 배포
      • SemVer

  • Component

    • 기술적인 요소들로 카테고리 구성
      • DataBase
      • Server

📜 Coding

BE

FE

  • 파일명: PascalCase
    • ex) App.js, Home.js
  • 변수 및 메서드: camelCase
    • ex) onSubmit
  • Redux
    • type명: SNAKE_CASE
      • ex) const LOGIN_SUCCESS = “LOGIN_SUCCESS”

🎰 Versioning

💡 Semantic Versioning 소프트웨어 버전 변경 규칙 (SemVer)

v1.0.0 [Major] . [Minor] . [Patch]

Major Version : 기존 api 변경 및 삭제 / api 하위 호환이 되지 않는 변경 (Breaking changes)
> Minor Version : 신규 기능(api) 추가 및 개선된 버전
> Patch version : 버그가 수정된 버전

📜 Semantic Versioning 규칙 📜
❗ Major Version이 올라가면 Minor Version, Patch Version은 0으로 변경한다.
❗ Minor Version이 올라가면 Patch Version은 0으로 변경한다.
❗ 각 Version은 자연수로 1씩 증가한다.
❗ SemVer 사용하는 소프트웨어는 반드시 공개 API를 선언해야 한다.
❗ API 코드 자체에 설명을 하거나, 공개 API 문서로 명시한다.