여러 프로젝트들 돌아다니면서 정해봤습니다. 논의 규칙을 줄이거나 상세화 해봐요!!

Merge 규칙

• 약속
  • PR 검토 완료 후 Merge합니다.
  • 자신이 올린 PR은 자신이 Merge합니다.
  • Merge 직전/직후에 바로 팀원들에게 공유합니다.
    • → 다른 사람들은 fetch로 변경사항 확인 → pull로 로컬로 가져옵니다. (이전 작업있으면 stash 후 pull 후 작업이어가기)
• 기본: squash and merge
  • squash는 여러 커밋을 하나로 합쳐줍니다. (커밋 메시지만 정리)
  • 지저분한 커밋 내역을 하나의 커밋으로 묶어서 병합 → 기능단위 커밋이 추가됨
• develop → main: rebase
  • 참고글1: https://seosh817.tistory.com/240 참고글2: https://techblog.woowahan.com/2553/
  • 위 글들을 보면 rebase는 깔끔한 history 관리, 이로 인한 버그 추적 용이, 에러 해결로 코드 품질 개선 등의 장점이 있다고 합니다.

Issue & Pull Request 규칙

• 제목: type: 무엇을 하는지 명확하게 적기.
  • 끝은 동사형 명사로 끝냅니다 ex. feat: 질문 카드 정렬 기능 추가 ex. bug: 하나 선택시 전체 선택 버그 수정
• 필수내용: 작업내용 (체크리스트 형태), 스크린샷, 리뷰어에게
• 선택내용: 실제 소요시간
• 필수선택: Assignees, Label, Reviewers

[ 참고 ]

• Label

커밋 컨벤션

• Angular JS Commit Convention을 기반으로 정했습니다.
• type keyword (헷갈리면 팀원들과 함께 결정해요!)
  • feat: 기능 추가
  • fix: 버그 수정
  • docs: 문서 작업
  • style: 세미콜론 추가, 띄어쓰기, 코드 포맷팅 수정 등
  • refactor: 버그수정과 기능추가 외 코드 수정, 코드&폴더 구조 개선, 폴더 이동, 파일 및 폴더명 수정
  • design: 기능 수정 없이 스타일만 수정
  • chore: 기타 수정, 코드에 변경사항 없음. 프로젝트 유지와 관련된 작업
  • test: 테스트 관련 작업
• rule
  • type 뒤 띄어쓰기 없이 콜론(:), 오른쪽에는 한 칸 띄우기
  • 문장은 동사형 명사로 끝냅니다. (개조식)
  • 특수 문자는 사용하지 않습니다.
  • type은 영어 소문자로, description은 한글로 작성합니다.