✅ Code convention
camel Case 사용
firstName = "John";
lastName = "Doe";
// class 명
function isNamingRule() {
}operators ( = + - * / ) 뒤 space로 공백
let x = y + z;
const myArray = ["Volvo", "Saab", "Fiat"];variable - 복수의 경우, 단수 + list의 형태를 사용
users (X) user+List (o)
categorys (x) category+List (O)variable & method - 되도록 full name 지향
userInfo (X) userInformation (o) userProfile (o)꼼꼼한 주석 작성
기능에 대한 설명이나
front / backend 처리하는 부분에 있어 이해가 필요하다고 생각되는 부분에
주석을 꼼꼼히 작성
주석의 긴 내용의 경우 함수나 class 상단에 작성
✅ commit convention
| 구분 | 예시 | |
|---|---|---|
| Feature | 새 기능 추가 | Feature / 로깅 시스템 구현 |
| Fix | 버그 수정 | Fix / AAAA 에러 수정 |
| Refactor | 코드 리팩토링 | Refactor / main 코드 리팩토링 |
| Modify | 기존 기능 수정 | Modify / main 수정 |
| Chore | 주석 추가 / 코드 포맷 변경 등 코드에 영향력을 미치지 않는 소소한 작업 | Chore / main 영역 주석 추가 |
| Hot Fix | 긴급 수정 | Hot Fix / 파일 제거 안되는 이슈 긴급 수정 |
PR message는 위의 커밋 메시지 중 가장 핵심이라고 생각되는 부분으로 올립니다.
prettieric
=> F / B 설정하여 포맷팅 맞춤. 한 줄 수정했을 때 포맷팅이 달라서, 전체 코드가 변한 것으로 간주되는
상황을 막기 위함. 완료 ✔️
💡 주석으로
// prettier-ignore을
입력하면 해당 줄 구문이 prettier 문법이 적용되지 않은 상태로 출력이 됩니다.
💡 단, Prettier가 적용되기 이전으로 돌린 뒤 주석을 적어야 적용이 됩니다.
Prettier setting이 되지 않는다면 prettier enable유무 확인, settings.json에서 format on save를 체크해주세요.
lint는 보류
✅ branch management strategy
dev -> master
✅ dev : 기본적인 작업물을 올리는 브랜치
backend와 front 소스는 기본적으로 이 브랜치를 기반으로 동작하며 특별한 상황이 아닌 이상
해당 dev 브랜치를 기준으로 pull & push 가 이루어짐.
기능 단위로 로컬 브랜치 파서 원격 브랜치에 푸시하고 그걸 원격 dev에 pr 날리고
- pr 날리고 merge 되면 기존 원격 브랜치 삭제 (옵션 체크)
- 본인 제외 최소 1명 이상의 approval 필요 (assign) => 올린 사람이 리뷰 확인 후 resolve & merge
- (웹 훅으로 pr 알림 전송 고려)
- 최소 하루 한 번 이상 비 정기적인 merge (상황에 따라 변할 수 있음)
- hot fix의 경우 스스로 merge 가능
✅ master : 최종 배포용 소스 코드 담을 브랜치
아주 급한 사항이 아닌 이상 바로 master 브랜치로 올리는 것은 지양
staging에서 이미 pr를 날려서 코드에 대한 검증과 리뷰를 마친 것으로 간주,
master로 pr하는 경우는 없을 예정. 바로 merge 가능
Ref
[우아한 형제들 기술 블로그] https://techblog.woowahan.com/9804/
prettier 파일이 적용안될 때 https://tesseractjh.tistory.com/220 참고
지속적으로 업데이트 될 예정입니다.
