코드 컨벤션
저희는 통일성을 유지하고 개발 프로세스를 더 효율적으로 하기 위해서 Prettier를 사용합니다.
Q. Prettier가 뭔가요?
A. Prettier는 다양한 언어를 지원하는 일관적이고 명확한 코드 포맷터입니다. 대부분의 언어에서 지원하는 기본적인 스타일링을 제거하고, 주어진 스타일에 따라 코드를 포맷합니다.
.prettierrc 설정
{
"printWidth": 80,
"tabWidth": 2,
"useTabs": true,
"semi": true,
"singleQuote": true,
"jsxSingleQuote": true,
"trailingComma": "es5",
"bracketSpacing": true,
"bracketSameLine": false,
"arrowParens": "always"
}
JSON
복사
이렇게 설정한 .prettierrc 파일은 작성된 코드들의 최상단(root) 디렉토리에 포함되어야 합니다.
리액트 프로젝트이기 때문에, src 폴더 바로 아래(내부)에 존재하면 됩니다.
그리고 VSC에서 Format on save 옵션을 켜 두면 코드를 작성하고 저장할 때 마다 .prettierrc 파일을 기반으로 Prettier가 자동으로 코드를 포맷합니다.
이외의 코드 컨벤션
•
의미있는 변수명을 사용합니다. 함수명은 동사로 시작합니다.
•
var 사용을 금지합니다. 변수 선언 시에는 let과 const 둘 중 하나만 사용해 주세요.
•
들여쓰기 시에는 tab만 사용합니다.
•
한 줄에 한 문장만 허용합니다.
•
JS, JSX에서 변수는 Camel Case로 선언합니다. CSS에서는 케밥 케이스를 사용합니다.
◦
thisIsCamelCase
◦
this-is-camel-case 케밥 케이스는 모든 문자가 소문자로 시작하며, 단어 사이에 하이픈(-)이 들어갑니다.
커밋 컨벤션
커밋 컨벤션이란
여기서 말하는 커밋 컨벤션이란, commit message 에 대한 약속입니다.
Q. 왜 지켜야 하나요?
A. 더 나은 소통과 협업 환경을 위해서 사용합니다
커밋 메시지 구조
커밋 메시지는 다음과 같은 세 가지 구조로 나뉩니다: 제목, 본문, 꼬리말
// 제목 (Subject)
type: Subject
// 본문 (Body)
본문 내용
// 꼬리말 (Footer)
꼬리말 내용
Plain Text
복사
그렇다면 각각의 요소들이 어떻게 작성되어야 하는지 알아봅시다.
제목
제목은 크게 Commit Type과 Subject Rule 두 가지로 나눌 수 있습니다.
Commit Type
Type | 설명 |
Feat: | 새로운 기능 추가 |
Fix: | 버그 및 오타 수정 |
Refactor: | 리팩토링 |
Design: | CSS 등 사용자 UI 디자인 변경 |
Comment: | 필요한 주석 추가 및 변경 |
Style: | 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 |
Test: | 테스트 |
Chore: | 이외의 변경사항 |
Init: | 프로젝트 초기 생성 |
Rename: | 파일 혹은 폴더명 수정 / 이동 |
Remove: | 파일 삭제 작업만 수행할 때 |
Subject Rule
1.
제목은 50글자를 넘기지 않습니다.
2.
마침표 등 특수기호를 사용하지 않습니다.
3.
첫 글자는 대문자로, 명령문을 사용합니다. ex) Add login
4.
요점을 포함해서 간결하게 작성합니다.
본문
본문에는 조금 더 자세하게 커밋의 내용을 담습니다.
1.
한 줄당 72자 내로 작성합니다.
2.
최대한 상세히 작성합니다
3.
무엇을 , 왜 변경했는지 작성합니다.
꼬리말
꼬리말은 선택입니다. 이슈가 발생하지 않았을 경우 굳이 작성하지 않아도 됩니다.
1.
유형: #이슈 번호 의 형식으로 작성합니다.
2.
이슈 트래커 ID를 작성합니다.
3.
여러개의 이슈 번호는 ,로 구분합니다.
이슈 트래커 유형은 다음과 같습니다:
Issue Tracker | 설명 |
Fixes: | 이슈 수정중 |
Resolves: | 이슈를 해결한 경우 |
Ref: | 참조한 이슈가 있을 때 사용 |
Related to: | 해당 커밋에 관련된 이슈 번호 (해결되지 않은 경우) |
커밋 템플릿
…저 긴 걸 언제 다 쓸까요? 그래서 기억하기 쉽게 커밋할 때 템플릿으로 사용하는 방법이 있습니다.
# 제목은 최대 50글자까지 아래에 작성: ex) Feat: Add Key mapping
# 본문은 아래에 작성
# 꼬릿말은 아래에 작성: ex) Github issue #23
# --- COMMIT END ---
# <타입> 리스트
# feat : 기능 (새로운 기능)
# fix : 버그 (버그 수정)
# refactor : 리팩토링
# design : CSS 등 사용자 UI 디자인 변경
# comment : 필요한 주석 추가 및 변경
# style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# docs : 문서 수정 (문서 추가, 수정, 삭제, README)
# test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore : 기타 변경사항 (빌드 스크립트 수정, assets, 패키지 매니저 등)
# init : 초기 생성
# rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 한 경우
# remove : 파일을 삭제하는 작업만 수행한 경우
# ------------------
# 제목 첫 글자를 대문자로
# 제목은 명령문으로
# 제목 끝에 마침표(.) 금지
# 제목과 본문을 한 줄 띄워 분리하기
# 본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
# 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# ------------------
# <꼬리말>
# 필수가 아닌 optioanl
# Fixes :이슈 수정중 (아직 해결되지 않은 경우)
# Resolves : 이슈 해결했을 때 사용
# Ref : 참고할 이슈가 있을 때 사용
# Related to : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
# ex) Fixes: #47 Related to: #32, #21
Plain Text
복사
저희는 이 템플릿을 적용시켜서 커밋을 진행할 예정입니다.
어…?? 어떻게 하면 템플릿을 적용 가능한가요? → 내일 같이 해 볼 예정입니다. 블로그 글을 숙지하고 와 주세요
브랜치 전략
Q. 브랜치 전략은 왜 사용해야 하나요?
A. 매끄러운 개발 절차와 브랜치 관리를 위해서입니다.
우리의 브랜치 전략, GitHub Flow
Q. 왜 GitHub Flow인가요?
A. 기존에 존재하는 Git Flow보다, GitHub Flow는 main branch에 대한 규칙만 정립되어 있다면 나머지 브랜치들에 대해서는 특별한 관여가 필요 없기도 하고, 개발부터 배포까지의 흐름이 단순하기 때문입니다.
대략적인 GitHub Flow의 모식도
GitHub Flow는 다음과 같은 흐름을 따릅니다.
branch 생성 → 개발 & commit & push → PR 생성 → 리뷰 & 토의 → 테스트 → 최종 merge
GitHub Flow의 흐름
branch 생성
•
main branch는 항상 최신 상태여야 하며, 안정적인 상태로 프로덕트에 배포되는 branch이기 때문에 엄격한 기준을 두고 관리해야 합니다.
•
feature나 develop branch가 따로 존재하지 않기 때문에, branch 이름은 가능하면 자세하게 작성하도록 합니다.
•
새로운 branch는 언제나 main에서 뻗어나온다는 것을 기억합시다!
개발 & commit & push
•
commit 메시지는 항상 명확하게 작성합니다. (commit convention 참고)
•
수시로 push 합니다.
•
항상 remote에 자신의 작업물을 올려서 다른 사람들도 확인할 수 있도록 합시다.
PR 생성
피드백, 도움이 필요할 때, merge 준비가 완료되었을 때 PR을 생성합니다.
코드리뷰, 토의
PR이 main branch와 합쳐진다면 바로 라이브 서버에 배포되는 것과 다를 바 없기 때문에, 충분한 리뷰와 토의를 거쳐서 merge하도록 합시다.
테스트
•
라이브 서버에 배포해서 테스트를 진행합니다.
•
만약 문제가 생긴다면 바로 재배포해서 main branch를 안정적인 상태로 유지합니다.
최종 merge
테스트 과정에서 문제가 없을 경우, 바로 main branch에 push후 배포를 진행합니다.
