From c0b2a3e3554b6d60d8e06cef78719a181b561c9a Mon Sep 17 00:00:00 2001 From: le2sky Date: Wed, 20 Sep 2023 01:41:38 +0900 Subject: [PATCH] =?UTF-8?q?docs=20:=20=ED=98=91=EC=97=85=20=EA=B0=80?= =?UTF-8?q?=EC=9D=B4=EB=93=9C=20=EB=AC=B8=EC=84=9C=ED=99=94?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/tech.md | 115 +++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 112 insertions(+), 3 deletions(-) diff --git a/docs/tech.md b/docs/tech.md index 31dcda1..0448000 100644 --- a/docs/tech.md +++ b/docs/tech.md @@ -5,8 +5,22 @@ ## 목차 - [목차](#목차) -- [의존성 제한](#의존성-제한) -- [코드 품질 제한](#코드-품질-제한) + - [의존성 제한](#의존성-제한) + - [코드 품질 제한](#코드-품질-제한) + - [일관성 있는 코드](#일관성-있는-코드) + - [린트 도구](#린트-도구) + - [협업 방법](#협업-방법) + - [이슈 등록](#이슈-등록) + - [이슈 라벨](#이슈-라벨) + - [이슈 네이밍](#이슈-네이밍) + - [신규 브랜치 생성](#신규-브랜치-생성) + - [브랜치 네이밍](#브랜치-네이밍) + - [개발 중 커밋 컨벤션](#개발-중-커밋-컨벤션) + - [풀 리퀘스트](#풀-리퀘스트) + - [풀 리퀘스트 네이밍](#풀-리퀘스트-네이밍) + - [풀 리퀘스트 라벨링](#풀-리퀘스트-라벨링) + - [테스트 전용](#테스트-전용) + - [메인 브랜치 반영 이후](#메인-브랜치-반영-이후) ## 의존성 제한 @@ -17,11 +31,106 @@ ## 코드 품질 제한 +### 일관성 있는 코드 + - 코드 베이스 반영 전에 import 최적화를 수행합니다. - 코드 베이스 반영 전에 불필요한 공백이 있는지 확인합니다. - 테스트가 실패할 경우, 코드 베이스에 절대 반영하지 않습니다. - 프로젝트 라인 커버리지 제한은 70% 이지만, 90% 이상을 목표로 합니다. - 중요하지 않은 hotfix를 제외한 모든 유형의 코드 반영은 PR을 통해 이루어져야 합니다. -- develop 코드 베이스에 반영할 경우 gpt 리뷰를 받습니다. +- 모든 develop 브랜치에 병합되는 PR은 협업자간에 코드 리뷰를 수행합니다. + - 만약, 시간적인 제약으로 인해서 코드 리뷰를 받지 못하는 경우에는 PR에 `run: gpt code review` 라벨을 붙이고 ChatGPT에게 리뷰를 받습니다. + +### 린트 도구 + +- 린트와 인텔리제이 코드 자동 정렬 설정을 협업자간에 동일하게 구성합니다. +- git commit 이전에 린트 검사를 수행합니다. + - commit 이전에 자동으로 스타일 검사를 수행하기 위해서 다음 명령어로 Hook을 등록합니다. + - `./gradlew addKtlintCheckGitPreCommitHook` +- 린트로 인해 빌드가 안될 경우에 빌드 디렉터리에 들어가 원인을 파악하고 코드를 수정합니다. + - 코드를 수정한 다음, `./gradlew ktlintCheck` 를 수행해 린트 검사 결과를 최신화합니다. + - 만약, 어떻게 코드를 수정해야하는지 모르겠다면, `./gradlew ktlintFormat` 을 수행해 코드를 자동 수정할 수 있습니다. + +## 협업 방법 + +### 이슈 등록 + +새로운 작업을 하기 이전에 깃헙 이슈를 등록합니다. + +#### 이슈 라벨 + +이슈에 등록 가능한 라벨의 유형은 다음과 같습니다. problem은 problem 이슈 템플릿을, 나머지는 task 이슈 템플릿을 사용합니다. + +- `new` : 신규 개발 +- `enhancement` : 리팩터링과 최적화를 비롯한 개선 작업 +- `chore` : 설정을 비롯한 부수적인 작업 +- `problem` : 문제 발생 +- `documentation` : 문서화 + +#### 이슈 네이밍 + +- 이슈의 이름 형식은 `[type] title` 입니다. + +- 이슈의 이름 형식 타입은 PR에서 사용하는 제목의 타입과 동일합니다. 단, PR 제목 타입에는 `배포`가 추가됩니다. + - `기능 구현` : new + - `개선` : enhancement + - `설정` : chore + - `문서` : documenation + - `문제` : problem + +### 신규 브랜치 생성 + +현재 개인 환경에 있는 브랜치가 저장소에 있는 최신 코드인지 확인하고, **develop 브랜치**에서 신규 브랜치를 생성합니다. + +#### 브랜치 네이밍 + +- 브랜치의 이름 형식은 `type/이슈 번호` 입니다. + +- 브랜치 이름의 타입은 다음과 같습니다. (앵귤러 JS 커밋 컨벤션의 타입을 따름) + - `feat` : new + - `refactor` : enhancement + - `chore` : chore + - `fix` : problem + - `docs` : documentation + - 기타 추가 가능 + +### 개발 중 커밋 컨벤션 + +개발 시 커밋 메시지는 [앵귤러 JS 커밋 컨벤션](https://gist.github.com/stephenparish/9941e89d80e2bc58a153)을 따르되, `type` + `subject`까지만 +작성해도 괜찮습니다. + +### 풀 리퀘스트 + +#### 풀 리퀘스트 네이밍 + +- 개발이 끝나면 develop 브랜치로 PR을 생성합니다. +- 풀 리퀘스트 이름 형식은 이슈 형식과 거의 동일합니다. +- 차이점은 PR 뒤에 () 내부에 연관 이슈를 추가하는 것입니다. + - 예시 : `[문서] 가이드 문서 작성(issue#58)` +- 관련 이슈가 한 개가 아니라면 구분자를 콤마(,)를 이용해 나열합니다. +- **(중요)** main 브랜치에 반영되는 경우에는 `[배포]`를 접두어로 사용하고, `deployment` 혹은 `no-deployment` 라벨을 등록합니다. +- **(중요)** main 브랜치에 반영되는 경우에는 () 내부에 연관 PR을 추가합니다. + - 예시 : + - `[배포] 메인 브랜치 반영(PR#23,PR#28)` : 버전이 증가하지 않는 경우 + - `[배포] v0.0.1(PR#12,PR#98)` : 버전이 증가하는 경우 + +#### 풀 리퀘스트 라벨링 + +- 현재 풀 리퀘스트의 라벨을 이용해서 자동으로 실행하는 github actions 작업이 존재합니다. + - `run: ci` : 빌드, 테스트, 테스트 커버리지 분석, 린트, 정적 코드 분석 실행 + - `run: gradle test` : 빌드, 테스트, 테스트 커버리지 분석 실행 + - `run: gpt code review` : ChatGPT 코드 리뷰 실행 + - `no-deployment` : 컨테이너 이미지 저장소(docker hub)에 신규 이미지 릴리즈하지 않음 + +#### 테스트 전용 + +- `[테스트]` 접두어를 사용하고, `ignore` 라벨을 등록합니다. +- 테스트 전용 PR은 코드 베이스에 반영하지 않습니다. + +### 메인 브랜치 반영 이후 + +- 개인 개발 환경에서 머지 커밋을 포함한 최신 main 브랜치의 코드를 내려받습니다. +- 태그를 만들고, 태그를 저장소에 push 합니다. +- 해당 태그로 새로운 릴리즈 노트를 작성합니다. [⬆ 위로 올라가기](#목차)