Skip to content

Latest commit

 

History

History
126 lines (91 loc) · 4.91 KB

1차리드미.md

File metadata and controls

126 lines (91 loc) · 4.91 KB
Raw

1. Github 컨벤션

  1. 1개의 feature 단위로 브랜치 생성
  2. 1개의 feature 단위로 issue 생성
  3. 1개의 issue 내에 세부작업마다 commit 을 날려
  4. 1개의 feature 끝나면 pull request 열어 ⇒ 머지 하면 ⇒ 해당 issue close

🔥Issue Convention🔥

## 화면 이름

## 기능 설명

## 필요 태스크
- [ ] Task1
- [ ] Task2
  • 한글로 쓰기
  • 명령조 사용하기 (수정(o)수정한다(x))
  • issue 제목
    • [화면명] 이슈명
  • github label
    • commit prefix 과 동일하게 만들 예정
    • 팀원 이름 추가
    • pull request 라벨 추가 (풀리퀘할 때 달기)

🔥Commit Convention🔥

commit message convention

  • #{issue_number} [prefix] 작엽명

  • ex) #1 [feat] 로그인 버튼 클릭 이벤트 처리

    (이슈를 생성하면 이슈 번호가 부여됨. 커밋할 때 이슈단으로 커밋하고 이슈번호를 커밋메시지에 #과 함께 적어주면 어떤 이슈를 처리하는 작업이었는지 조회하기 편함.)

  • commit message 마지막에 마침표(.) 찍지 않기

    • commit prefix
      • [feat] : 기능 추가, kotlin 작업
      • [layout] : xml 작업
      • [fix] : 에러 수정, 버그 수정
      • [docs] : README, 문서
      • [refactor] : 코드 리펙토링 (기능 변경 없이 코드만 수정할 때)
      • [modify] : 코드 수정 (기능의 변화가 있을 때)
      • [chore] : gradle 세팅, 위의 것 이외에 거의 모든 것

🔥PR Convention🔥

##관련 이슈번호

##화면 이름

##완료 태스크
-
-

  • 한글로 쓰기

  • 명령조 사용하기 (수정(o)수정한다(x)

  • 제목: issue 번호 + issue 제목

    ex) #5 [습관방] 습관방 디자인

  • 내용: 템플릿 형식을 따르며 풀리퀘에서 해결한 이슈들의 이슈번호,화면이름, 완료테스크를 이슈별로 정리해서 작성한다.

2. 코드 컨벤션

what naming rules example
function Lower Camel Case fun sparkFunction
variable Lower Camel Case val/var sparkVariable
class Upper Camel Case: :class SparkClass
interface Upper Camel Case interface SparkInterface
const val Screaming Snake Case const val SPARK_VALUE
xml file name Snake Case activity_main.xml
fragment_spark.xml
item_spark(where)feed(what).xml
menu(where)(what).xml
selector(where)_(what).xml
xml id Snake Case tv(view)_main(where)_nickname(what)
drawable file name Snake Case selector_main(where)_btn_join(what)
colors.xml Lower Camel Case
Snake Case
Upper Camel Case		 디자이너가 정해준 컬러 이름으로
strings.xml Snake Case [where]_[what]
styles.xml Snake Case [where]_[what]
function name 초기화 ⇒ init~
갱신 ⇒ update~
삭제 ⇒ remove~
통신 ⇒ get, delete, put, post
이름에 따라서 함수명 ⇒ getUserList(), postUser(), putProfile		 set[ItemName]ClickListener
set[AdapterName]Adapter
set[ValueName]Observe()

3. 폴더 구조

  1. 패키지 네임은 무조건 소문자로 작성한다.

  2. 패키지는 크게 data 패키지, di패키지, ui패키지, util 패키지로 나눈다.

  3. data 패키지

    • data 패키지는 크게 local 패키지와, remote 패키지, repository 패키지로 나눠진다.
    • local 패키지에는 로컬 저장소에서 SharedPreference와 관련된 파일들이 들어간다.
    • remote 패키지에는 외부 저장소(서버)에서 오는 model(responseData, requestData 등), api(service 등)등이 들어간다.
    • repository 패키지에는 레포지토리 파일(도메인 역할)들이 들어간다.

  4. di 패키지

    • di패키지에는 의존성 주입(Hilt)과 관련된 코드(Module)들이 들어간다.

  5. ui 패키지

    • ui 패키지는 크게 base 패키지와, view 패키지, viewmodel 패키지로 나눠진다.

    • base 패키지

      • base 패키지에는 뷰들이 상속받는 베이스 클래스(BindingActivity, BindingFragment)가 들어간다.

    • view 패키지

      • view 패키지에는 프로젝트 내에서 사용되는 뷰(액티비티나, 프래그먼트, 어댑터, 모델 등)와 관련된 클래스들이 들어간다.
      • 연관있는 클래스(ex : 로그인, 회원가입)들은 패키지 한 곳에 보관한다.
      • 커스텀 뷰의 경우 각 view에 대한 패키지 하위에 custom 패키지를 따로 두어 거기서 관리한다.

  6. util 패키지

    • util 패키지에는 확장함수나, 다양한 util 관련 파일들이 들어간다.

4. 브랜치 전략

  • master / develop / feature / hotfix

  • master, develop, feature/화면_작업명 (브랜치 삭제, 생성 매번 해줘야함)

  • feature/{feature-name} 이슈추적을 사용한다면 이와 같은 형식을 따른다.

    ex) feature/init-project, feature/build-gradle-script-write

  • 브랜치명 예시

    feature/init-project