1. 개요

이 문서는 구글의 Java언의 코딩 표준의 완벽한 정의 문서이다. 자바 소스 파일은 이 문서의 규칙을 고수해야만 Google Style이라 칭할 수 있다.

다른 프로그래밍 스타일 가이드 처럼, 주제들은 포매팅같은 심미적인 주제뿐만 아니라, 다른 관습들 혹은 코딩 규칙들도 포함한다. 그러나 이 문서는 우리가 보편적으로 따르는 엄격한 규칙에 초점을 맞추고 있으며 명백히 실행할 수 없는 조언들을 주는 것을 지양한다.

2. 수정

해당 내용을 프로젝트에 맞게 수정하였다.

Doc의 내용은 없애고, 자주 의견이 달라질 수 있는 부분만 정리하였다.

☕Java Coding Convention

$$ \Huge\bf{🚨~Issue/PR ~Convention} $$

Issue

우측 담당자(Assignees) 탭을 활용하여 명시한다.
Task list 기능을 적극 활용한다.
기능에 관련된 Issue라면 Github Project와 PR과 연동하여 진행상황을 공유한다.

Pull Request

제목은 자유롭게 작성하되 본문 하단에 이슈를 연동한다
PR 시 반드시 1명 이상의 승인을 받고, 요청 본인이 MERGE 한다.

$$ \Huge\bf{🌈~Branch} $$

브랜치는 main branch, develop branch, feature branch 를 사용하며 추가적인 브랜치는 feature의 하위로 생성한다.

🧷작업 규칙

작업을 시작하기 전, Issue를 발행한다.
하나의 이슈는 가능한 하나의 커밋으로 한다.
자신의 Pull Request는 스스로 merge 한다.

🧷branch 규칙

추가 기능 작업 시 develop 브랜치에서 항상 분기하여 feature 브랜치를 생성한다.
생성된 feature 브랜치의 수명은 되도록 짧게 가져간다.(자주 push하고 생성)
항상 develop은 Pull Request를 통해 merge한다.
QA중 버그가 발생할 시, 기존의 규칙대로 feature를 생성하거나, hotfix 브랜치를 생성한다.(특별히 구분하진 않는다.)

$$ \Huge\bf{🌞~Commit~Convention} $$

커밋 컨벤션은 아래의 내용을 참고하여 작성한다.

Udacity Nanodegree Style Guide

Tag Name	Description
feat	새로운 기능 추가
fix	버그 수정
style	코드 스타일 혹은 포맷 등에 관한 커밋
refactor	프로덕션 코드 리팩토링
docs	문서 수정
test	테스트 코드, 리펙토링 테스트 코드 추가
build	빌드 관련 파일 수정 / 모듈 설치 또는 삭제에 대한 커밋
chore	그 외 자잘한 수정에 대한 커밋

[!NOTE]

본문의 내용은 Subject, Body, Footer 로 구분하여 작성한다.

Subject
feat : 제목은 50자 이내, 영문 작성 시 대문자로 시작하며 마침표를 사용하지 않는다

Body
해당 영역은 선택 사항으로, 설명과 컨텍스트가 필요할 경우 사용한다.
커밋의 내용과 코드의 작성 이유를 설명하려면 해당 영역을 사용한다.
Body와 Subject는 빈 줄을 반드시 추가하다.

Footer
선택사항이며, 이슈 ID를 작성한다.

Resolves: #123