HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
🧚
[1기]최종 프로젝트 데브코스/
[팀3] 아이육
[팀3] 아이육/
🎁
Front Git 컨벤션
🎁

Front Git 컨벤션

최종 편집일
Dec 15, 2021 03:26 PM
날짜
Nov 28, 2021 04:46 PM
상태
규칙
담당자
영후 김

1. 커밋 메시지

(1) 작성 방법

  • 제목 : 제목은 명령조로 작성하여, 목적을 명확히 한다.
  • 본문
    • 제목과 구분하기 위해 한 줄을 띄우고 작성한다.
    • 부연 설명으로 본문이 필요할 때는, 한 항목 당 72자 내외로 작성한다.
    • 'How'보다 'What'과 'Why'에 대한 설명을 작성한다.
    • 작업 단위로 완료된 시점에서만 커밋을 하여 불필요한 커밋을 최소화한다.

(2) 작성 예시

Feat: SearchModal 마크업 추가
Fix: SearchModal StatusInputName 레이아웃 조정
Feat: ProfileMoreInfoPage 관심 지역 저장 구현

(3) 커밋 타입

  • Feat : 기능 추가 / 변경 (현재 상태로 배포되었을 때 유저 입장에서)
  • Fix : 버그 수정 (현재 상태로 배포되었을 때 유저 입장에서)
  • Refactor : Feat나 Fix가 아닌 코드의 개선 (변수 / 함수명 변경, 가독성 개선 등)
  • Style : 내용 변경 없는 코드 포맷 수정 (세미콜론, 공백 등)
  • Chore : 빌드 업무 수정, 패키지 매니저 수정 (라이브러리 추가, package.json .gitignore 수정 등)
  • Rename: 파일 혹은 폴더명을 수정하는 경우
    • renamed: public/logo.png -> public/images/logo.png (위치 변경도 포함)
  • Remove: 사용하지 않는 파일 혹은 폴더를 삭제하는 경우
  • Docs : README, Git Template 관련

2. PR 제목

PR 제목은 다음과 같은 형태로 작성합니다.

Commit Type: [컴포넌트명] [구현내용] [액션]

Feat: SigninPage 마크업 추가
Feat: SigninPage 로그인 구현
Feat: MainPage 무한스크롤 구현

Fix: PostDetailsPage 마크업 수정
Fix: PostCreatePage 입력 없을 때 요청 가능한 버그 수정

Refactor: ShelterPostsPage 무한스크롤 리팩토링
  • PR 제목에 Feat와 같은 Commit Type 을 붙이는 이유? squash merge 할 때 develop으로 들어가는 커밋 메시지명과 동일하게 하기 위함입니다.
  • squash & merge 하는 이유? squash는 하나의 commit으로 develop에 merge 하기 위함입니다. 이는 PR 단계부터 작업 단위를 명확하게 나누도록 합니다. 또한 develop에 merge되는 commit을 큰 단위로 흐름을 파악하기 쉽게 나타낼 수 있습니다.
  • commit type 을 하나로 정하기 어렵다면? 먼저 PR을 분리해야 한다는 신호일 수 있으므로 작업을 적절히 나누었는지 살펴봅니다. 분리하기 어렵다면 가장 중요한 작업 내용으로 커밋 타입을 정합니다.

3. PR 내용

PR 내용은 다음과 같은 형태로 작성합니다.

### 이슈 번호 <!-- 관련된 이슈의 번호를 # 뒤에 입력해주세요  -->

- close: #

### 특이 사항 <!-- PR을 볼 때 미리 알아야 하거나, 주의 깊게 봐야 하는 점을 알려주세요 -->

- 특이 사항 1
- 특이 사항 2
  • 가급적 모든 팀원이 approve 하는 것을 규칙으로 하며, 최소 1명의 approve는 받아야 합니다.
  • 원격에 PR을 올리기 전에
    • 컴파일 오류가 없음 확인
    • 최신 develop 브랜치의 소스 위에서 수정이 진행 되었는지 점검
      • 최신 develop에서 pull 받고, conflict가 발생한 경우 해결해서 PR
      • conflict 해결에 어려움이 있다면 즉시 팀원 호출
    • 프로젝트 셋업 이후 develop에 직접 push 금지
    • what에 대한 주석과 같은 불필요한 주석을 삭제하고 (why에 대한 주석은 무관), console.log를 삭제
  • PR의 assignee가 피드백을 확인하고 develop에 직접 merge
    • 코드리뷰로 진행된 피드백을 확인하고, 반영할지 말지 본인이 선택
    • 피드백에 대해 active에서 resolved로 바꾸는 것도 본인 선택.
      • 피드백을 수용한다면 수정 후 resolved
    • develop에 merge할 때는 squash merge를 사용해주세요!

4. 브랜치

  • main : 릴리즈가 아니면 푸시를 하지 않습니다. develop에서만 머지합니다. hotfix가 아닌 경우 직접적으로 건들면 안 됩니다.
  • develop : feature 브랜치를 파생시킬 수 있는 일반적인 작업 브랜치입니다. feature 브랜치의 PR은 무조건 develop으로 날립니다. develop에서 각 개발자들의 작업 내역을 합쳐서 릴리즈시 main로 머지합니다.
  • feature : PR의 단위입니다. develop에서 파생시켜 각자 맡은 내역을 작업한 후 develop에 PR을 날립니다. 브랜치를 생성할때 개발자이름/피처-브랜치-이름 형식을 따릅니다.

5. 스타일 컨벤션

  • 단일 파일 컴포넌트 구현을 위해 해당 컴포넌트에만 매핑되는 스타일시트를 작성하는 것을 권장합니다. 따라서 하위 컴포넌트나 컴포넌트 범위 바깥에 영향력을 끼칠 수 있는 CSS 프로퍼티 작성을 지양합니다.

6. 코드리뷰 체크리스트 (펌)

  1. 컴파일 에러 : 에러가 발생하는 코드를 PR 해서는 안 됩니다.
  1. 컨벤션 : 팀의 코드 컨벤션에 어긋나는 부분이 있는지 점검합니다. 변수명이나 함수명, 이벤트명 등이 직관적으로 이해되지 않는다면 부담 없이 코멘트를 남깁니다. 새로운 파일이 생성되었다면 생성된 파일이 적합하고 가시성 있는 위치에 컨벤션을 준수하여 저장되어 있는지 확인합니다.
  1. 컴포넌트 구조 : 컴포넌트의 네스팅 깊이가 너무 깊어 특정 코드에 접근하기 어렵거나 너무 얕아 코드의 재사용성이 떨어지고 특정 파일이 특히 길어진다던지 하는 컴포넌트 구조와 배치를 확인합니다. 수정된 컴포넌트의 구조가 확장에 용이한지 살핍니다.
  1. 최적화 : 불필요한 http 요청이 있지는 않은지, 렌더링 과정에서의 부하나 불필요한 컴포넌트의 재랜더링이 이루어지고 있지는 않나 확인합니다.
  1. 중복 : 컴포넌트들 사이에서 같은 로직과 코드를 하드코딩해서 사용하고 있지는 않나 확인합니다. 그런 로직이 있다면 util로 분리하는게 좋습니다.
  1. UI : 직접 브랜치를 내려받아 돌려보시고, 무슨 문제인지 눈으로 직접 보고 판단하는게 좋습니다. 귀찮은 일일지도 모르겠습니다만, 더 나은 팀을 위해서는 적극적으로 서로의 실수를 검증하는 깐깐한 자세가 필요하다고 생각합니다.