📎 커밋컨벤션 (커밋 규칙)

• 깃허브 이슈 브랜치 삭제하지 말기!

<aside> 💡 [CHORE] 코드 수정, 내부 파일 수정

[FEAT] 새로운 기능 추가

[BUG] 버그, 오류 수정

[DOCS] README 등의 문서 수정

[REFACTOR] 전면 수정(코드 리펙토링)

[TEST] 테스트 코드 추가 및 수정

</aside>

• 커밋

  [feat] 유저 생성함 
  

브랜치 전략

• git-flow 의 일부 브랜치 사용
  • main : 현재 배포되어 있는 브랜치
  • develop : 개발 진행중인 브랜치
  • feature : 기능 구현중인 브랜치
• [커밋컨벤션]/[이슈번호]-[기능세부]

ex) feat/1-create-user 

PR 관리 프로세스 (개발자)

• 개발 전
  • 이슈 생성하여 이슈에 구현할 기능들의 목록 작성
  • 이슈 번호에 맞춰 feature 브랜치 생성
    • develop 브랜치를 최신 버전으로 가져온 후(fetch) develop 을 기준으로 브랜치 생성
      • fetch → local develop checkout → remote develop pull
• 개발 진행
• 개발 후
  • remote 브랜치로 push
    • 로컬 브랜치에서 충돌이 발생하더라도 롤백을 간단하게 하기 위함
  • local develop 브랜치에 remote develop 브랜치 변경 사항 fetch
    • 다른 개발자가 구현한 기능 반영
  • local develop 브랜치에 변경된 내용이 있을 경우 local feature 브랜치로 rebase
    • rebase : 이전의 커밋 이력들을 그대로 가져옴
    • merge : 이전의 커밋 이력들을 새로운 커밋으로 가져옴
  • 충돌 발생할 경우 조심해서 충돌 해결… 🥹
• 코드리뷰가 끝날 경우 본인 PR 은 본인이 Merge 진행
  • Squash Merge

코드리뷰 프로세스 (리뷰어)

• PR 에 한 명 이상의 개발자가 리뷰(approve) 를 해주어야 Merge 가능
• 리뷰 작성하기

  • PR 에 Files changed 선택

    

  • 코멘트 달고 싶은 라인을 선택하여 리뷰 작성

    

  • 리뷰를 모두 달았다면 Review changes 버튼 선택하여 리뷰 적용

    

    • comment : 댓글 작성 (리뷰X)
    • approve : 코드를 승인하고 싶은 경우
    • request changes : 코드에 변경이 필요하다고 생각되는 경우