협업 전략 정하기

[tableMinPark]

할일

• Git 브랜치 전략 정하기
• Git 커밋 전략 정하기
• Issue & PR 전략 정하기

[tableMinPark]

Issue & PR 전략

• 작업할 주제는 항상 Issue 를 생성해서 기록
• Issue 에는 작업내용, 작업할 항목, 담당자, 참고사항 등을 기록
• PR 을 진행할 때는 1명의 코드 리뷰를 통해 승인되어야 머지가 가능하도록 설정
• PR 에는 "참고사항" 문단을 만들고 related issue : #1 방식으로 Issue 번호를 적기
• 한 PR 에는 가능한 하나의 기능의 변경만 담기, 커밋 수 최소화해서 1, 2개 정도로 유지하기

[tableMinPark]

Git 브랜치 전략

• 브랜치 : main -> release -> develop -> [서브 프로젝트명] -> feat/, fix/, refactor/, config/
• main, release, develop, [서브 프로젝트명] 브랜치는 PR 로만 커밋 가능
• [서브 프로젝트명]/ 브랜치
  • 서브 모듈 프로젝트 브랜치 (각 모듈별 브랜치)
  • develop 브랜치에서 생성 -> develop 브랜치로 PR -> squash 머지
  • 하나의 기능 개발이 완료되어 모든 테스트 코드를 통과할 시 PR 진행
• feat/ 브랜치:
  • 기능 개발 및 테스트 코드 브랜치 (실제 기능상의 변경이나 기능을 추가할 시)
  • [서브 프로젝트명] 브랜치에서 생성 -> [서브 프로젝트명] 브랜치로 PR -> squash 머지
• fix/ 브랜치:
  • 버그 발생 시 픽스 브랜치
  • [서브 프로젝트명] 브랜치에서 생성 -> [서브 프로젝트명] 브랜치로 PR -> squash 머지
• refactor/ 브랜치
  • 실제 기능은 변함없지만 명칭만 변경했을 시 브랜치
  • [서브 프로젝트명] 브랜치에서 생성 -> [서브 프로젝트명] 브랜치로 PR -> squash 머지
• config/ 브랜치
  • (작성중)

[tableMinPark]

Git 커밋 전략

• conventional commit 을 간소화하여 사용
• 커밋 제목은 태그, 내용으로 구성 : feat: 회원 가입 컨트롤러 개발
• 태그는 feat, fix, refactor,config 만 사용
• 커밋 바디 형식은 자유롭게 작성, 해당 커밋의 내용을 요약할 것

[tableMinPark]

테스트 전략

• 테스트용 환경 설정 파일 application-test.yml을 생성하여 테스트 환경만의 설정 파일을 만든다.
• @TestPropertySource(locations = "classpath:application-test.yml")을 통해 테스트용 환경 파일을 사용하도록 한다.
• DisplayName()에는 테스트하는 항목 설명을 기입한다. (ex. 회원 id를 입력하지 않아도 id가 등록된다.)
• repoository 단위테스트는 @DataJpaTest를 사용해 내부 DB를 통해 진행한다.