• 기본적으로 할 일을 나누어서 깃헙 이슈에 올린다.
• 이슈들을 묶어서 마일스톤으로 만들고, 일정을 산정해서 수행.
• PR은 남이 읽는 것!! 길면 안 된다.
• diff 500줄 이내로. 이것 때문에 이슈를 잘게 나누는 것.
• 감정을 넣지 않는 것.
• approve가 2명 이상 되어야 PR을 머지할 수 있다. 이 때, 리뷰 대상은 PR을 작성한 자신이며, 리뷰어는 다른 세 명의 팀원이다.
  • PR의 길이가 길면 인식시켜줄 필요는 있다. PR에 리액션을 단다던지, 댓글을 단다던지.
• 브랜치 전략은 Git-flow를 사용!
  • main, develop 브랜치가 있다.
  • 새 기능을 개발할 경우, develop 브랜치 위에서 feature/(기능이름) 브랜치를 만들고 그 위에서 작업한다.
    • 이 때 기능 이름은, 각 이슈의 제목과 연관되게 설정한다.
  • 그날그날 PR을 날릴 때는 작업하던 feature 브랜치를 공동 저장소의 develop 브랜치에 머지 요청한다.
  • 주마다 배포 버전을 만들 때는 release/(버전) 브랜치를 만들고, develop 브랜치의 현재 진행 상황을 가져온다.
  • 핫픽스가 필요한 경우 hotfix/(버전) 브랜치를 만들고 그 위에서 수행한다.
  • 릴리즈를 위한 작업이 끝난 경우 release 브랜치를 태그와 함께 develop 브랜치에 머지하고, main 브랜치에 develop 브랜치를 머지해 준다. (이 과정에서 develop 브랜치는 살아 있어야 함)
  • 브랜치 이름은 소문자만 사용하며, 하이픈(-)으로 단어 사이를 구분한다.