개발 문화 형성기 - 커밋컨벤션, 코드컨벤션

히징·2024년 7월 18일
0
post-thumbnail

💙 컨벤션 형성 계기

회사에 입사하고나서 내가 제일 먼저 놀랐던 것은 우리팀의 개발 문화의 부재였다.
커밋컨벤션 하나 없이 중구난방으로 작성된 커밋메세지가 제일 먼저 눈에 띄였고, 코드 또한 컨벤션이라 할 것이 없어보였다.
그래서 회의 때나 커피타임 때 종종 커밋컨벤션이나 코드컨벤션이 중요할 것 같다고 언급은 했었으나, 실현되지는 않았고 답답한 나머지 팀 전체로 바꾸기가 어렵다면 프론트엔드 파트에서 먼저 시행해보자!!! 하고 커밋컨벤션과 코드컨벤션을 정하게 되었다.

원래 우리팀에서 프론트엔드 개발자는 나 혼자뿐이어서 혼자 나름 컨벤션을 정해서 쓰고있었는데, 다른팀의 프론트엔드 개발자분께서 우리팀에 합류하게 되면서 내가 기존에 쓰고 있던 컨벤션을 체계화해서 사용하게되었다.

💙 팀 내에서도 공통된 컨벤션을 적용하자!

그렇게 약 1년간 프론트엔드에서만 컨벤션을 지키며 사용하고있었는데 여러 프로젝트들을 하면서 다른 직군들과도 통일할 필요성이 있다는것을 느끼게 되었다.

마침 팀장님과 이야기 나눌 일이 생겨서 진지하게 현재 프론트엔드 파트에서 이러한 컨벤션을 정해서 사용하고있고, 업무 효율이 상승했기에 팀내에도 적용하는게 좋을 것 같다고 건의했다. 직군이 다르니 코드컨벤션은 파트 내에서 알아서 하더라도 개발팀 내의 커밋 컨벤션은 통일했으면 좋겠다고 말씀드리게 되었다.

나는 사실 회의때 몇번 의견을 말했을때 다들 반응이 별로 없어서 원하지 않는다고 생각했었는데 팀장님께서 다른 팀원분들이 무엇을 해야할 지 확실하게 정의되지 않아서 그럴 것이라며 다음 개발팀 회의때 내가 직접 팀에서 사용했으면 하는 커밋컨벤션을 준비해와서 발표해봐라고 하셨다.

그렇게 기존 프론트엔드파트에서 사용하고 있던 커밋컨벤션을 중심으로 통일된 컨벤션을 위해 깃에서 커밋템플릿을 작성하는 방법까지 발표하게 되었고 현재 팀내에서 모두 통일된 컨벤션을 간편하게 사용하고 있게 되었다.

다음은 프론트엔드 파트에서 실제로 사용하고 있는 컨벤션이고, 코드 컨벤션을 제외한 커밋컨벤션 부분은 개발팀 전체에서 통일하여 사용하고있다!!

입사 첫날부터 신경쓰였던 묵은 때를 벗겨낸 느낌이라 너무 홀가분하고 내 의견이 적극 반영되어 팀내에서 통일되게 사용하고 있는것이 너무 뿌듯했다. 팀의 협업환경에 작게나마 기여할 수 있어서 영광이었다.

Frontend Convention

  • HTML / CSS / JS 모두 들여쓰기는 2칸입니다.
  • W3C validator를 통과할 수 있도록 웹 표준에 맞게 작성
  • 시맨틱 태그 사용 및 접근성을 고려하도록 노력하기

CSS 속성 순서 ( 참고 )

1. display
  1.1 justify-content
  1.2 align-items
  1.3 기타 flex, grid 관련 속성들...
2. overflow
3. float
4. position
  4.1 top / bottom / left / right
  4.2 z-index
  4.3 transform
5. width / height
6. padding / margin
7. border
8. background
9. color / font
10. animation
11. 기타

따옴표

  • js 작은 따옴표 우선 사용
  • html 큰 따옴표 사용

JS


  • ES6+ 문법 사용
  • var 금지
  • 세미 콜론 필수
  • 작은 따옴표 사용

변수명

  • 일반적인 변수, 함수: camelCase
let myVar = 1;

const myArr = [1, 2, 3];

function myFunction() {

}
  • 상수: UPPER_SNAKE_CASE
const MAX_NUM = 10;
  • 생성자 함수, 클래스: PascalCase
function MyFunction(title) {
  
}

class MyClass {

}

폴더 명


  • 직접적으로 바로 컴포넌트들이 들어있는 컴포넌트 폴더명은 대문자로 시작한다. PascalCase
  • 직접적으로 바로 컴포넌트들이 들어있지 않은 폴더명은 소문자로 작성한다.

파일 명


  • HTML: kebab-case

  • CSS: kebab-case

  • JS: camelCase

  • JSX: PascalCase

  • ASSET: snake_case

커밋 컨벤션


💡 커밋은 논리적으로 구분이 되고, 일관성이 유지되는 단위로 최대한 작게 쪼갠다.

1. Commit 메세지 구조

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

body

footer

2. Commit Type Rule

  • 태그는 영어로 소문자로 작성합니다.
  • 태그 뒤에는 “: “을 붙입니다. ( 콜론 뒤에만 한 칸 띄움 )
Commit TypeDescription
feat새로운 기능 추가
fix버그 수정
designCSS 등 사용자 UI 디자인 변경
style코드 포맷팅, 세미 콜론 누락 등 코드 변경이 없는 경우
refact코드 리팩토링
del코드 삭제 수행
add에셋 또는 기타 파일 추가
rename파일 혹은 폴더명 수정하거나 옮기는 경우
remove파일 삭제만 수행
test테스트 추가 (프로덕션 코드 변경 없는 경우)
chore빌드 또는 패키지 관리자 설정 업데이트
init초기 설정
set초기 설정 이후의 추가 설정

3. Subject Rule

  • 제목은 최대 50글자가 넘지 않도록 하고 마침표 및 특수기호는 사용하지 않는다.
  • 영문사용 시, 동사원형 사용하고, 과거 시제를 사용하지 않는다.
  • 제목은 개조식 구문으로 작성한다. -> 완전한 서술형 문장이 아니라, 간결하고 요점적인 서술을 의미.

4. Body Rule

  • 본문은 한 줄 당 72자 내로 작성한다.
  • 본문 내용은 양에 구애받지 않고 최대한 상세히 작성한다.
  • 본문 내용은 어떻게 변경했는지 보다 '무엇을', '왜' 변경했는지를 설명한다.
  • 꼬릿말은 다음의 규칙을 지킨다. 1. 유형: #이슈 번호의 형식으로 작성 2. 이슈 트래커 ID를 작성 3. 여러개의 이슈 번호는 ,로 구분 4. 이슈 트래커 유형은 아래와 같다
    • 꼬리말은 optional이고 이슈 트래커 ID를 작성한다.
    • 꼬리말은 "유형: #이슈 번호" 형식으로 사용한다.여러 개의 이슈 번호를 적을 때는 쉼표(,)로 구분한다.
    • 이슈 트래커 유형은 다음 중 하나를 사용한다.
      -  Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
      -  Resolves: 이슈를 해결했을 때 사용
      -  Ref: 참고할 이슈가 있을 때 사용
      -  Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
💡 **커밋 예시**

feat: add signin, signup
회원가입 기능, 로그인 기능 추가(예시를 위해 간단히 작성)
Resolves: #1

  • commit template
    ###########################
    ### 제목(Subject) - (영문기준) 50자 이내
    # <커밋 타입>: <제목>    * 콜론 뒤만 한칸 띄움
    # 변경사항이 "무엇"인지 명확히 작성 / 끝에 마침표 금지
    # ex) feat: 로그인 기능 추가
    # 바로 밑줄에 작성
    
    # 바로 아래 공백은 지우지 마세요 (제목과 본문의 분리를 위함)
    
    ###########################
    ### 본문(Body) - 한 줄당 최대 72자, 초과시 줄바꿈 
    # (1) 무엇을 (2) 왜 (3) 어떻게 수정했는지
    # 바로 밑줄에 작성
    
    # 바로 아래 한 줄 공백 유지 (본문과 바닥글의 분리를 위함)
    
    ###########################
    ### 꼬릿말(Footer) - (선택)
    # ex) Close #7
    # 바로 밑줄에 작성
    
    ###########################
    ### [커밋 타입 목록]
    # feat    : 새로운 기능 추가
    # fix     : 버그 수정
    # design  : CSS 등 사용자 UI 디자인 변경
    # style   : 코드 의미에 영향을 주지 않는 변경사항 ( 코드 포맷변경, 세미콜론 누락 등 )
    # del     : 코드 삭제
    # add     : 에셋 또는 기타 파일 추가
    # docs    : 문서 수정
    # refact  : 코드 리팩토링
    # test    : 테스트 코드 추가 (프로덕션 코드 변경 X)
    # chore   : 빌드 부분 혹은 패키지 매니저 수정사항 (프로덕션 코드 변경 X)
    # rename  : 파일 혹은 폴더명을 수정하거나 옮기는 작업
    # remove  : 파일 삭제만 수행
    # init    : 초기 설정
    # set     : 초기 설정 이후의 추가 설정
    ###########################

✅ git commit ⇒ 템플릿 접속 ⇒ 빈칸에 제목, 본문(선택), 꼬릿말(선택) 작성

  • 제목에서 이미 내용을 다 설명하고있어 본문에 쓸 내용이 없는 경우 제외하고는 본문 작성 권장 !

템플릿 등록

내 로컬 즉 commit 할 때마다 사용해주고 싶다면 "~/"를 앞에 붙여서 파일을 생성

touch ~/.gitmessage.txt

이번 프로젝트에서만 사용하고 싶다면 ~/을 빼주고 파일을 생성

touch .gitmessage.txt
vim ~/.gitmessage.txt  
or
vim .gitmessage.txt

template 저장

git commit template 설정

git config --global commit.template ~/.gitmessage.txt
or
git config --global commit.template .gitmessage.txt 
git commit 

폴더 구조


*아토믹 패턴

  • atom
  • module
  • template
  • page

참고 :
https://chlolisher.tistory.com/173
https://overcome-the-limits.tistory.com/entry/협업-협업을-위한-기본적인-git-커밋컨벤션-설정하기

profile
FE DEVELOPER 👩🏻‍💻🤍

0개의 댓글

관련 채용 정보