Portfolio

Ground Rule

아만드팀 협업 컨벤션

💻 Commit 규칙

< 예시 >
[C] feat: 어쩌구저쩌구 #1

1. 팀 카테고리

팀별 상위 카테고리를 명시

카테고리명

설명

[C]

커뮤니티 팀

[M]

마켓 팀

2. 커밋 종류

두 번째로 수정한 종류에 따라 커밋 메시지를 선택

메시지명

설명

feat

새로운 기능 추가 관련

fix

버그 수정

test

테스트 코드, 리팩토링 테스트 코드 추가

refactor

코드 리팩토링(기능향상)

chore

빌드 업무 수정, 패키지 매니저 수정

docs

문서 수정(md, git관련 파일, 이미지파일 수정)

style

코드 formatting, 세미콜론(;) 누락, 코드 변경이 없는 경우

3. 관련 이슈

작성한 커밋과 관련된 이슈 번호를 매핑

이슈 번호뒤에 아래에 써놓은 명령어를 붙여서 커밋 날리면 자동으로 이슈가 close 된다.close / closes / closed / fix / fixes / fixed / resolve /resolves / resolved

🌳 Branch 규칙

Git Flow 전략 찍먹하기

사용할 브랜치는 총 3개이다

main : 최종 완료된 변경사항을 반영하는 브랜치

develop : 기능 구현을 반영하는 브랜치

feature : 기능 단위로 생성되는 브랜치

feature 브랜치

<예시>
[c|m]/user-login

팀이 두개로 나눠져 있으므로 feature 네이밍은 c나 m으로 변경

feature 브랜치 네이밍은 위처럼 구현할 기능을 명시한다.

1 issue == 1 branch 로, feature 브랜치를 생성하기 전에 이슈를 먼저 생성한다

기능 구현이 끝나면 develop 브랜치로 PR를 날려 코드리뷰를 진행~

PR이 merge되면 해당 feature 브랜치는 삭제한다.

하면 혼나는 일

독자적으로 main 브랜치 변경

PR 없이 main, develop 브랜치에 merge

안쓰는 브랜치 삭제 안하는 행위

기타 컨벤션

Java : Camel Case

DB : Schema, Table, Column -> Snake Case

패키지 구조 : 도메인형

api 주소 : api/도메인명/... (단기 프로젝트이므로 버저닝은 생략한다)