그라운드 룰 - boostcamp-2020/Project15-B-Client-Based-Formula-Editor GitHub Wiki

커밋 메시지 규칙

# <타입>: <제목>
(여기에 제목)
##### 제목은 최대 50 글자까지만 입력 ############## -> |

# 본문은 아래에 작성
(여기에 본문)
######## 본문은 한 줄에 최대 72 글자까지만 입력 ########################### -> |

# 꼬릿말은 아래에 작성: ex) #이슈 번호
(여기에 꼬릿말)
# --- COMMIT END ---
# <타입> 리스트
#   feat    : 기능 (새로운 기능)
#   fix     : 버그 (버그 수정)
#   refactor: 리팩토링
#   style   : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
#   docs    : 문서 (문서 추가, 수정, 삭제)
#   test    : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
#   chore   : 기타 변경사항 (빌드 스크립트 수정 등)
#   init    : 초기 환경 설정
# ------------------
#     한글로!
#     제목 끝에 마침표(.) 금지
#     제목과 본문을 한 줄 띄워 분리하기
#     본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
#     본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# ------------------

PR

• 화면의 변경사항은 캡쳐를 추가해주면 좋다.
• PR 내용에 변경사항과 추가사항을 구분해서 작성한다.
• fork를 따서 작업 : Upstream [master - dev] < PR < Origin [feature]
  • 
• Conflict 발생 시 절차
  • 작은 것들은 GitHub 내부에서, 비즈니스 로직과 같이 중요한 부분들은 로컬로 땡겨와서 충돌을 해결한 뒤 반드시 검증(테스트)을 마치고 다시 PR을 날린다.
• 코드리뷰 방식, 문화
  • 적극적으로 리뷰하고, 적극적으로 수용 한다.
  • 리뷰에는 이유가 있어야 한다.
  • 그 리뷰를 수용할지 말지는 선택이다. 만약 수용하지 않는다면 그 이유가 있어야한다.

이슈 템플릿 사용

• 문제 및 해결 방안

  • title: Current Problems and Solutions
    desc: 문제를 발견하고 이를 해결하기 위한 이슈 템플릿
    ### 👉 Problem 
    - 현재의 문제
    
    ### 🏀 Solution
    - 해결 방안
    
    ### 👊 So We
    - 그래서 우리는 이렇게 하자
    

• 피쳐

  • title: Issue for Feature 
    desc: 새로운 기능을 위한 이슈 템플릿
    ### 🤙 To Do 
    - [ ] 할 일1
    - [ ] 할 일2
    
    

EsLint는 네이버 컨벤션을 따른다.

명명 규칙(Naming Convention)

• 카멜 케이스: 변수, 함수명
• 파스칼 케이스: 파일, 컴포넌트명

브랜치 네이밍

• master
• develop (default branch)
• feature/branch-name

GitHub Actions 적용

컴포넌트 단위 테스트 적용

PR은 3명 모두 Approve하면 Merge 가능

import 규칙 : 라이브러리 주루룩 한줄 띄우고 파일 주루룩

Issue, Project, Milestone 대신 Backlog를 활용한다.

• Issue는 백로그에 정의된 기능 외에 추가 기능이나 문제가 있어 수정해야하는 task 등을 제시할 때 사용한다.