❗ 코드 컨벤션이 필요한 이유

• 유지보수, 기능 고도화는 꼭 해당 코드를 작성한 사람만 하는 것이 아니다.
• 팀 이동, 혹은 이직을 통해 새로운 환경의 코드를 만날 수도 있다.
• 개발을 하면서 수없이 다른 사람의 개발 코드를 만나고 이해해야한다.
• 이때, 생산성을 높이기 위해 코딩 컨벤션을 준수해야한다.

💬 컨벤션을 정하면서 느꼈던 점

• SI 업체에서 3년 씩이나 일을 했으면서도 컨벤션을 처음 설정해봤다.
• 웹개발이 주력인 회사가 아니었을 뿐더러 본인이 맡은 프로젝트는 끝까지 본인이 책임졌기 때문에(평균 근속 연수 약 4년) 코드를 공유 할 일이 많이 없었어서 그랬던 것 같다.
• 그나마 과장님과 내가 웹개발을 도맡아 하면서 코드를 공유했었는데, 당시에는 변수명 정도만 정했어서 코드 수정 후 넘겨받을 때 마다 코드를 분석하는게 일이었다.
• 이번에 팀 컨벤션을 정하면서 생각보다 사소한 것까지(ex:''사용과 ""사용) 정해야 해서 처음에는 시간낭비라고 생각했는데, 한 번 제대로 정해놓고 나니 팀원들끼리 코드 리뷰하기도 편해졌고, 코드를 합치고 나서도 수정할 부분이 적어져서 좋았다.

---

1. Commit Message

• Git과 GitHub은 단순한 버전관리도구를 넘어선 문서 & 협업 툴이다. 개발자가 다른 개발자의 코드를 분석할 때 목적&시기를 확인하기 위해 제일 먼저 확인하는 것은 Git Commit Message이다.

• Git의 가장 기본적인 문서인 커밋 메시지를 잘 작성하는 것은 중요하다.

• 팀으로 작업을 진행한다면 팀의 커밋 메시지 규칙을 정하는 것은 필수적이다. 그러나 커밋 메시지에는 정석, 정해진 규칙은 없으므로 레퍼런스를 찾아보고 논의하는 과정을 거치면서 다듬어나가야 한다.

참고자료 : Commit Message Guidelines, How to Write Good Commit Messages: A Practical Git Guide

2. History 관리 및 브랜치 관리 전략

• 개별 커밋 메세지도 중요하지만 프로젝트의 전체 흐름이 어떻게 이루어져 있는지를 보기위해서는 전체 커밋의 히스토리를 확인해야한다.

• 이 때 만약 main의 commit history가 뒤죽박죽으로 섞여있으며 불필요한 커밋들이 섞여있다면 전체 히스토리를 파악하기가 힘들어진다.

• 작업중일때는 원하는만큼 커밋을 남기되, 최종적으로 브랜치의 작업이 완료되고 PR을 통해서 main에 머지 요청을 하기 전 원하는 형태로 git squash로 커밋을 정리해준다.

참고자료 : Git 스쿼시 커밋

3. 우리 팀 Git Convention

👉 Commit Message

• Conventional Commit 방식 사용

<type>[optional scope]: <description>

[optional body]

[optional footer]


// 예제
feat(signup): 회원가입 API 연결 및 회원가입 포맷 작성 

PR close: #3999


// 예제
feat(docs-infra): add v8 to the version picker 
in the navbar(#35196)

The v8.angular.io should be ready shortly.

PR Close #35196

👉 Branch Name

• feature/admin/JH : 구현중인 기능이 겹치면 이니셜 기재(JH)

👉 Commit Type

• type(optional scope): 내용작성
• feat : 새로운 기능 추가 및 기존 기능 변경
• fix : 버그 수정 (기존 기능 변경 없이 bug 수정하는 경우)
• BREAKING CHANGE : API 호환성이 바뀌거나 라이브러리를 변경하는 경우 사용
• docs : 문서 수정
• style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
• design : CSS 등 사용자 UI 디자인 변경
• refactor : 코드 리펙토링
• test : 테스트 코드, 리펙토링 테스트 코드 추가
• chore : 빌드 업무 수정, 패키지 매니저 수정

👉 PR Convention

• feature 브랜치(작업) 단위로 PR을 작성
• “[기능] 제목”형식으로 PR 제목을 작성
• 내용은 템플릿의 형식 따름