[Git] Git Convention

☑️ 깃 컨벤션

1. Git

1.1. Rules

1.1.1. Git Flow

기본적으로 Git Flow 전략을 이용한다. 작업 시작 시 선행되어야 할 작업은 다음과 같다.

1. Issue를 생성한다.
2. feature Branch를 생성한다.
3. Add - Commit - Push - Pull Request 의 과정을 거친다.
4. Pull Request가 작성되면 여유가 있으면 Code Review를 한다.
5. Code Review가 완료되면 Pull Request 작성자가 develop Branch로 merge 한다.
6. merge된 작업이 있을 경우, 다른 브랜치에서 작업을 진행 중이던 개발자는 본인의 브랜치로 merge된 작업을 Pull 받아온다.
7. 종료된 Issue와 Pull Request의 Label과 Project를 관리한다.

1.1.2. Etc.

협업 시 준수해야 할 규칙은 다음과 같다.

1. develop에서의 작업은 원칙적으로 금지한다. 단, README 작성은 develop Branch에서 수행한다.
2. 자신이 담당한 부분 이외에 다른 팀원이 담당한 부분을 수정할 때에는 Slack을 통해 변경 사항을 전달한다.
3. 본인의 Pull Request는 본인이 Merge한다.
4. Commit, Push, Merge, Pull Request 등 모든 작업은 앱이 정상적으로 실행되는 지 확인 후 수행한다.
5. README 수정을 위한 Commit 도배는 금지한다. 미리보기는 Preview를 통해 확인한다.

1.2. Branch

Branch의 Naming Rule은 1.2.1을 따른다. Branch는 가능한 한 작업단위, 기능단위로 생성하며 이는 Issue를 기반으로 한다. 단, 같은 범위의 기능이라면 같은 브랜치를 사용한다. 예를 들면, 회원가입 기능 구현 시 아이디 중복 체크, 비밀번호 확인, 아이디 유효성 확인 등은 회원가입 하나로 구분한다.

1.2.1. Branch Naming Rule

Branch를 생성하기 전 Issue를 먼저 작성한다. Issue 작성 후 생성되는 번호와 Issue의 간략한 설명 등을 조합하여 Branch의 이름을 결정한다. <Prefix>/<Issue_Number> 의 양식을 따른다.

1.2.2. Prefix

• main : 개발이 완료된 산출물이 저장될 공간
• develop : feature 브랜치에서 구현된 기능들이 merge될 브랜치
• feature : 기능을 개발하는 브랜치, 이슈별/작업별로 브랜치를 생성하여 기능을 개발한다

1.2.3. 예시

main
develop/v1.0.0
feature/10-sign-up

1.3. Issue

작업 시작 전 Issue 생성이 선행되어야 한다. Issue는 작업 단위, 기능 단위로 생성하며 생성 후 표시되는 Issue Number를 참조하여 Branch Name과 Commit Message를 작성한다.

이슈의 제목에는 기능의 대표적인 설명을 적고, 내용에는 세부적인 내용 및 작업 진행 상황을 작성한다.

이슈 생성 시 Github 오른편의 Assignee, Label, Project, Linked Pull Requests 를 적용한다. Assignee는 해당 이슈의 담당자, Label에는 담당자, TODO, 우선순위 등의 Label을 추가한다. 작업 대기중인 Issue에는 TODO, 작업 진행 중이면 In Progress를, 완료된 Issue에는 completeLabel을 추가한다.

1.3.1. Issue Naming Rule

[<PREFIX>] <Description> 의 양식을 준수하되, Prefix는 협업하며 맞춰가기로 한다. 또한 Prefix는 대문자를 사용한다.

1.3.2. 예시

[FEAT] 회원가입 구현
[DEBUG] MainActivity 버그 수정
[STYLE] 폰트 변경

1.4. Pull Request

Pull Request의 내용에는 변경된 사항에 대한 설명이 작성되어야 한다. 템플릿을 활용하여, 관련 이슈번호와 작업한 내용을 명시한다.

1.5. Code Review

Code Review는 변경 사항에 대해 궁금한 점, 코드 가독성(변수명, 함수명 등)에 대한 조언 등을 작성한다.

 

☑️ 커밋 컨벤션

1. 커밋의 타입

feat

major, minor 버전을 올리기 위한 새로운 피쳐 구현을 포함한다.

# 타이머 기능이 새로 추가된 경우
> [feat] 타이머 기능 추가

# 학습 결과 카드에서 새로운 정보를 더 보여주어야 하는 기능 삭제
> [feat] 학습 결과 카드에서 새로운 정보를 더 보여주는 기능 삭제

fix

patch 버전을 올리기 위한 수정 사항들을 포함한다.

# 장학금 퀘스트 안내의 텍스트가
# "장학금 퀘스트는 문화상품권으로 지급돼요!"에서
# "장학금 퀘스트는 네이버 페이 포인트로 지급돼요!"으로 변경된 경우
> [fix] 장학금 퀘스트 관련 문구 변경

# 학습 결과 카드들 사이의 간격이 12px에서 10px로 수정된 경우
> [fix] 학습 결과 카드 사이 간격 변경

chore

src 나 test 폴더를 건드리지 않는 잡다한 일을 포함한다.

# 새로운 프론트엔드 개발자가 들어와서 슬랙봇을 수정한 경우
> [chore] 슬랙봇에 아무개를 추가

refactor

feat나 fix에 포함되지 않는 코드 수정을 의미한다.

필요없는 파일을 제거한다거나, 파일의 위치를 옮긴다거나, 코드적인 개선사항을 포함한다.

# TextButton이 더 이상 코드에서 필요없어진 경우
> [refactor] 쓰이지 않는 TextButton 컴포넌트 삭제

> [refactor] MyButton 을 YourButton 이라는 이름으로 변경

> [refactor] MyButton.kt 위치 이동

> [refactor] 친구 정보 가져오기 API 리팩토링

env

개발 환경과 관련된 변경을 의미한다. CI/CD에 대한 변경이나, 빌드 과정에 대한 변경점을 포함한다.

# 안드로이드 빌드에 대한 변경점이 생긴 경우
> [env] 안드로이드 빌드 툴체인의 메모리 용량 2048MB -> 4096MB

revert

이전 커밋으로 되돌아가는 경우 발생하는 커밋이다.

2. 메세지 형식

커밋 메세지는 다음과 같은 형태로 작성한다.

> "[커밋의 타입] 커밋 메세지 내용"

• 커밋의 타입은 위에서 언급한 7가지 중에서 가장 적절한 것을 선택해 대괄호안에 작성한다. 타입에 맞게 잘 쪼개어 커밋을 남긴다.