Git Convention

Issue

• Issue 명은 다음과 같이 사용한다.
  • [feat] - Issue 명
  • [fix] - Issue 명

• Issue 사용 예시

Pull Request

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

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

• 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

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

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

• PR 체크 리스트

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

Code Review

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

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 정확히 이해하기