협업 방식 정의

Git 협업 방식 정의

Branch

• git flow 방식 채택
• 브랜치 구성
  • main: 배포
  • develop: 프론트와 백에서 작업한 내용을 통합
  • frontend/backend
    • 프론트/백에서 각각 작업한 feature 브랜치를 통합
    • CI(github action) 적용
  • feature
    • 명명규칙: [front | back]/feat/[#이슈번호]
    • 특정 feature에 대한 실제 개발 진행

Commit

commit 태그

• feat: 새로운 기능을 추가하는 경우.
• fix: 버그를 수정하는 경우.
• docs: 문서만 수정하는 경우.
• style: 코드의 의미에 영향을 주지 않는 변경(코드 포맷팅, 세미콜론 누락 등).
• refactor: 코드 리팩토링(기능 변경 없이 코드 개선).
• test: 테스트 추가 또는 기존 테스트 수정.
• chore: 빌드 작업이나 패키지 매니저 설정 등 변경 사항.
• design: 스타일링 작업하는 경우.

commit 메세지 예시

• commit 제목:

feat: 로그인 페이지 UI 개선 (#5678)

• commit 본문(선택):

로그인 페이지에 반응형 디자인을 적용하고, 오류 메시지 스타일을 업데이트했습니다.

- Flexbox를 사용하여 레이아웃을 개선했습니다.
- 오류 메시지 스타일을 통일하고 가독성을 높였습니다.
- 다양한 브라우저와 기기에서 테스트를 완료했습니다.

Closes #5678

Github 협업 방식 정의

Issue

• issue type
  • 기능 개발: feat
  • 버그 리포트: bug
  • 수정 이슈: fix
• issue 등록시 적절한 Assignees와 Labels 선택 필수

PR

PR 제목 컨벤션

• 태그: 변경 내용 ex) [FIX] timezone 관련 에러 수정
  • 태그는 변경 사항의 유형을 설명합니다. 예를 들어, feat, fix, refactor, docs, hotfix , test등이 될 수 있습니다.
  • 태그 형식은 대괄호 안에 대문자로 작성합니다. ex) [FEAT], [FIX], [REFACTOR] ...
  • 간결하면서도 핵심적인 변경 사항 설명을 제목에 포함합니다.

PR 본문 컨벤션

미사여구를 없애고 짧게 목적만 명세.
필요하다면 아래 목록과 같은 방식으로 설명해주세요.

• 무엇을: 이번 PR에서 구현한 내용.
• 왜: 이 변경이 필요한 이유.
• 어떻게: 변경 사항을 구현한 방법에 대한 설명.
• 관련 이슈: 해결한 이슈 번호 (예: Closes #1234).
• 테스트: 적용된 테스트 또는 테스트 방법.

Precaution

필요하다면 아래의 목록을 명세해주세요.

• 간단한 요약
• 추후 변경점(todo list)
• PR에 대한 애로사항
  • ex) 작업을 넘기기 위한 PR이라던가 등등…

코드리뷰

뱅크샐러드 코드리뷰 방식을 참고하여 진행 코드 리뷰 in 뱅크샐러드 개발 문화

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

• 버그와 잠재적인 버그로 인한 수정 필요시, 리뷰 요청자는 합리적인 의견을 기술해야한다.
• 코드 컨벤션(오타나 컴포넌트 선언 방식 등)을 틀렸을 경우에도 사용한다.

P2: 웬만하면 반영해 주세요 (Request changes)

• PR된 코드보다 더 좋은 방식의 접근법과 코드가 있다고 생각하거나, 코드 품질을 위해 변경이 필요하다면 리뷰 요청자는 합리적인 의견을 기술해야한다.
  • 구현했던 함수가 이미 존재한다.(함수 중복)
  • 로직을 hook으로 빼는 건 어떤가?(가독성) 등의 코드 품질에 대한 이야기.
  • (변경된 코드를 보여준다) 이런 방식은 어떠세요? 가독성이 향상될 것 같습니다.

P3: 방식 제안 또는 의견 (Comment)

• 기존 코드와는 다른 방식의 제안과 접근법을 제안할 때.
  • hook 대신 Query Options 을 사용하는 건 어떨까요?
• 기술적인 지식과 노하우를 공유할 때 사용한다.
  • (링크 참조) 이런 방식도 있더군요. 지금 동작도 문제는 없지만 이렇게 해도 괜찮을 것 같아요.
• 코드에 대한 설명을 요구하거나 의문이 생겼을 때. 해당 코드를 가리키면서 이 코드가 어떻게 동작하는지에 대한 요구.
  • 왜 이렇게 하셨죠? 다른 방식도 있지 않나요?

P4: 사소한 의견입니다 (Approve)

• 승인.