Skip to content

Git Convention

Jump to bottom
Kuesung Park edited this page Jul 2, 2023 · 12 revisions

Issue

  • Issue 명은 다음과 같이 사용한다.
    • [fix] - Issue 명
    • [setting] - Issue 명
    • [page] - Issue 명
    • [component] - Issue 명
    • [docs] - Issue 명
  • Issue 사용 예시 Issue 사용 예시

Pull Request

image

  • 각 기능 브랜치에 대한 PR의 제목은 깃모지 prefix : 브랜치를 총괄하는 내용 으로 한다.

    • 예시 : 📄 page : 회원가입 - 학교 이메일 인증 화면(step2)

  • PR 체크 리스트

    • Reviewer 지정
    • Assignees 지정
    • Label 붙이기
    • Projects 지정

Code Review

  • 리뷰어의 Approve 가 1개 이상일 때, 브랜치를 머지할 수 있다.
  • 코드 리뷰는 필수적으로 참여하되, 만약 리뷰 없이 이틀 경과 시에는 머지한다.
  • 코드 리뷰의 우선 순위에 따라 라벨을 사용한다.
    • ex) 우선순위: 급함 , 우선순위 : 보통, 우선순위 : 낮음
  • 소통을 위하여 코드 리뷰에 다음과 같은 접두사를 사용한다. (참고자료 - 코드 리뷰 in 뱅크샐러드 개발 문화)

P1: 꼭 반영해주세요 (Request changes)

리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

P2: 적극적으로 고려해주세요 (Request changes)

작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

P3: 웬만하면 반영해 주세요 (Comment)

작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)

작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

P5: 그냥 사소한 의견입니다 (Approve)

작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

Commit

  • Commit 은 가급적이면 기능 당 하나의 커밋을 사용한다.
  • Commit 메시지는 반드시 한글로 작성하며, 너무 길어지지 않도록 최대한 간결하게 작성한다.
    • Commit 메시지에 문장형을 사용하지 않는다.
    • Commit 메시지에 마침표를 사용하지 않는다.
  • husky 를 이용한 pre-commit 을 사용한다.
  • main 과 default 브랜치에 force-push 를 금지한다. (레포 설정)

Commit Message

commit prefix-convention

prefix 설명
✨ feat 새로운 기능을 추가할 경우
🐛 fix 버그를 고친 경우
💄 design CSS 등 사용자 UI 디자인 변경
🚑 hotfix 급하게 치명적인 버그를 고쳐야 하는 경우
🎨 style 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
♻️ refactor 프로덕션 코드 리팩터링
💡 comment 필요한 주석 추가 및 변경
📝 docs 문서를 수정한 경우
✅ test 테스트 추가, 테스트 리팩터링 (프로덕션 코드 변경 X)
🔧 env 프로젝트 환경 설정
🤡 mock msw 관련
🎉 init 프로젝트 첫 설정
🚚 rename 파일 혹은 폴더 명을 수정했거나 옮기는 작업만인 경우
🔥 remove 파일을 삭제하는 작업만 수행한 경우
📦 chore 빌드 태스트 업데이트, 패키지 매니저 설정 (프로덕션 코드 변경 X)
🍱 asset asset 관련 파일(favicon, font) 업데이트 작업만 수행했을 경우

Branch strategy

우리는 git flow 및 github flow와 같은 정형화 된 방식을 채택하지 않았다. 해당 전략은 우리가 개발하는 프로젝트의 규모에 비해 복잡성이 큰 편이기 때문에 짧은 개발시간 안에, 많은 기능을 구현하기 위하여 브랜치 전략의 최대한 간결하게 사용하기로 합의하였다.

따라서 아래의 최소한의 브랜치 전략을 채택하였다.

  • develop : 개발용 브랜치
  • 기본적으로 commit prefix 에 따라 기능을 나누고 이에 따른 기능 branch를 만들어 사용한다.
    • 예시 : feature/{issue-number} : 기능 구현 branch, fix/{issue-number} : 버그 수정 branch
  • 기능 브랜치를 develop 브랜치로 머지할 때는 squash and merge 를 사용한다.
  • 개발이 완료되고, develop 브랜치를 main 브랜치로 머지할 때는 rebase and merge 를 사용한다.
  • 참고 자료 : GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기
# Issue
  • Issue 명은 다음과 같이 사용한다.
    • [feat] - Issue 명
    • [fix] - Issue 명

이슈 사용 예시 Issue 사용 예시

Pull Request

image

  • 각 기능 브랜치에 대한 PR의 제목은 깃모지 prefix : 브랜치를 총괄하는 내용 으로 한다.

    • 예시 : 📝 docs: PR 템플릿 가이드 라인 추가

  • PR 체크 리스트

    • Reviewer 지정
    • Assignees 지정
    • Label 붙이기
    • Projects 지정

Code Review

P1: 꼭 반영해주세요 (Request changes)

리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

P2: 적극적으로 고려해주세요 (Request changes)

작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

P3: 웬만하면 반영해 주세요 (Comment)

작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)

작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

P5: 그냥 사소한 의견입니다 (Approve)

작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

Commit

  • Commit 은 가급적이면 기능 당 하나의 커밋을 사용한다.
  • Commit 메시지는 반드시 한글로 작성하며, 너무 길어지지 않도록 최대한 간결하게 작성한다.
    • Commit 메시지에 문장형을 사용하지 않는다.
    • Commit 메시지에 마침표를 사용하지 않는다.
  • husky 를 이용한 pre-commit 을 사용한다.
  • main 과 default 브랜치에 force-push 를 금지한다. (레포 설정)

Commit Message

commit prefix-convention

prefix 설명
✨ Component 컴포넌트를 구현한 경우
📜 Docs 문서를 수정한 경우
🐛 Fix 버그를 고친 경우
🆘 Help wanted 팀원의 도움이 필요한 경우
🐞 Bug 버그가 발생한 경우
📄 Page 페이지 컴포넌트를 구현한 경우
🔧 Setting 세팅을 진행한 경우

Branch strategy

우리는 git flow 및 github flow와 같은 정형화 된 방식을 채택하지 않았다. 해당 전략은 우리가 개발하는 프로젝트의 규모에 비해 복잡성이 큰 편이기 때문에 짧은 개발시간 안에, 많은 기능을 구현하기 위하여 브랜치 전략의 최대한 간결하게 사용하기로 합의하였다.

따라서 아래의 최소한의 브랜치 전략을 채택하였다.

  • develop : 개발용 브랜치
  • 기본적으로 commit prefix 에 따라 기능을 나누고 이에 따른 기능 branch를 만들어 사용한다.
    • 예시 : feature/{구현할 기능} : 기능 구현 branch, fix/{수정할 버그} : 버그 수정 branch
  • 기능 브랜치를 develop 브랜치로 머지할 때는 squash and merge 를 사용한다.
  • 개발이 완료되고, develop 브랜치를 main 브랜치로 머지할 때는 rebase and merge 를 사용한다.
  • 참고 자료 : GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기

Home

Project

Convention

스프린트

Release Note

외부 문서

Clone this wiki locally