[런닝 코스 공유 서비스] - 3. 컨벤션 & Git Branch 전략

프로젝트에서는 일관된 코드 품질 유지와 협업 흐름 및 협업 경험을 위해 
코드 컨벤션과 Git 전략을 명확히 정의하고 이를 기반으로 개발을 진행할 것이다

 

코드 컨벤션은 가독성과 유지보수성을 높이고, 

Git 전략은 변경 이력을 명확히 하고 안정적인 개발 흐름을 유지하기 위해 사용한다.

 

이 글에서는 프로젝트 전반에서 적용할 코드 컨벤션, Git 브랜치 전략에 대해 설명한다.

---

코드 컨벤션

• Google Java Style Guide 를 기본으로 사용한다.

네이밍 컨벤션

• 변수, 함수 : 카멜 케이스(camelCase)
  • 변수의 이름은 명사로 표기
  • 함수의 이름은 동사, 동사구문으로 표기 : 함수의 의미를 명확하게 알기 위해
• 클래스, 인터페이스 : 파스칼 케이스(PascalCase)
• 디렉토리, 패키지 : 스네이크 케이스(snake_case)
• 구현체 클래스 : Impl 접미사 사용
• 상수 : UPPER_SNAKE_CASE
• Boolean 변수 : is, has, can 등 접두사 사용
• 복수 변수 : list 접미사 사용
• 이벤트 핸들러 함수 : on 접미사 사용

---

커밋 메시지 구조

• 기본적인 커밋 메시지 구조는 제목, 본문, 꼬리말 세가지로 나누고, 각 파트는 빈줄을 두어 구분한다.

type: Subject -> 제목  
(한칸 띄우기)  
body(생략 가능) -> 본문  
(한칸 띄우기)  
footer(생략 가능) -> 꼬리말  

커밋 타입

• 타입은 태그와 제목으로 구성되고, 태그는 영어 및 첫 문자는 대문자로 한다.

Feat : 새로운 기능 추가
Bug : 버그 발견
Fix : 버그 수정
Docs : 문서 수정
Style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
Refactor : 코드 리펙토링
Test : 테스트(테스트 코드 추가, 수정, 삭제)
Chore : 기타 변경사항 (빌드 스크립트 수정, assets, 패키지 매니저 등)
Comment : 필요한 주석 추가 및 변경
Init : 초기 생성  
Rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 한 경우  
Remove : 파일을 삭제하는 작업만 수행한 경우  

Subject(제목)

• 제목은 최대 50글자가 넘지 않도록 하고 마침표 및 특수기호는 사용하지 않는다.
• 영문으로 표기하는 경우 동사를 가장 앞에 두고 첫 글자는 대문자로 표기한다.
  • 과거 시제를 사용하지 않는다.
• 간결하고 요점적으로 서술한다.

Body(본문)

• 본문은 한 줄 당 72자 내로 작성한다.
• 내용은 양에 구애받지 않고 상세히 작성한다.
• 어떻게 변경했는지 보다 무엇을 변경했는지 , 왜 변경했는지 설명한다.

footer(꼬리말)

• 유형: #이슈 번호 형식을 사용한다.
• 이슈 트래커 ID 를 작성한다.
  • Fixes: - 이슈 수정중
  • Resolves : - 이슈를 해결한 경우
  • Ref: - 참조할 이슈가 있을 때 사용
  • Related to: - 해당 커밋에 관련된 이슈 번호
• 여러 개의 이슈 번호를 적을 때 쉼표로 구분한다.
• ex) Footer에 Fixes: #1 이라고 작성하고 commit을 할 경우, 자동으로 issue #1과 매칭이 된다.

커밋 템플릿

# 제목은 최대 50글자까지 아래에 작성: ex) Feat: Add Key mapping  

# 본문은 아래에 작성  

# 꼬릿말은 아래에 작성: ex) Github issue #23  

# --- COMMIT END ---  
#   <타입> 리스트  
#   Feat        : 기능 (새로운 기능)  
#   Fix         : 버그 (버그 수정)  
#   Refactor    : 리팩토링  
#   Design      : CSS 등 사용자 UI 디자인 변경  
#   Comment     : 필요한 주석 추가 및 변경  
#   Style       : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)  
#   Docs        : 문서 수정 (문서 추가, 수정, 삭제, README)  
#   Test        : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)  
#   Chore       : 기타 변경사항 (빌드 스크립트 수정, assets, 패키지 매니저 등)  
#   Init        : 초기 생성  
#   Rename      : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 한 경우  
#   Remove      : 파일을 삭제하는 작업만 수행한 경우  
# ------------------  
#   제목 첫 글자를 대문자로  
#   제목은 명령문으로  
#   제목 끝에 마침표(.) 금지  
#   제목과 본문을 한 줄 띄워 분리하기  
#   본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.  
#   본문에 여러줄의 메시지를 작성할 땐 "-"로 구분  
# ------------------  
#   <꼬리말>  
#   필수가 아닌 optioanl  
#   Fixes        :이슈 수정중 (아직 해결되지 않은 경우)  
#   Resolves     : 이슈 해결했을 때 사용  
#   Ref          : 참고할 이슈가 있을 때 사용  
#   Related to   : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)  
#   ex) Fixes: #47 Related to: #32, #21  

---

Git 전략

개인 프로젝트이기 때문에 Git Flow 대신 Github Flow 전략을 사용하기로 결정했다.

브랜치 구조가 단순하고, 작은 단위의 변경을 빠르게 검증하기에 적합하다고 생각했기 때문이다.

GitHub Flow 전략의 장점

• 브랜치 구조가 간단하고 직관적이다.
• main 브랜치를 항상 배포 가능한 상태로 유지할 수 있다.
• 작은 규모의 변경 사항을 빠르게 테스트하고 검증할 수 있다.
• 독립적인 브랜치에서 진행되기 때문에 충돌이 발생할 가능성이 적다.

브랜치 구성

• main
  • 항상 동작하는 안정 브랜치
  • 배포, 제출 가능한 상태를 유지한다.
• feature
  • 기능 단위로 생성하는 브랜치
  • 하나의 기능 , 작업이 완료되면 main 브랜치로 병합한다.
• fix
  • 버그 수정 및 오류 대응을 위한 브랜치
  • 수정 완료 후 main 브랜치로 병합한다.
• docs
  • 문서, README 등 코드 외 작업을 위한 브랜치

운영 방식

• 모든 작업은 main 브랜치에서 직접 진행하지 않는다.
• 새로운 브랜치를 판다면 최신 브랜치를 가져온다.

---

참고자료

https://velog.io/@gmlstjq123/Git-Flow-VS-Github-Flow

https://m.blog.naver.com/so_no7/223507064379

https://kdjun97.github.io/git-github/commit-convention/

https://m.blog.naver.com/so_no7/223507064379

https://techblog.woowahan.com/9804/

https://m.blog.naver.com/so_no7/223507064379