1. 사람에 대한 리뷰가 아닌, 코드에 대한 리뷰를 하자.
2. 각자의 삶의 방식과 생체 리듬을 존중해주자.
3. 궁금할 때는 바로 질문하자.
4. 사소한 것이라도 피드백하되, 기분이 상하게 하지 말자.
5. 피드백을 수용할 줄 아는 자세를 갖자.
6. 밥은 먹고, 잠은 자면서 하자.
7. 지각하지 말자.

• 오전 10시, 최대 15분
• 목적 : 퇴근 이후 추가 작업한 내용이 있으면 짧게 브리핑 후, 당일날 할 일 브리핑
• 사담 금지
• 스크럼 진행자가 zoom 화면공유로 타이머를 켜놓고 1인당 3분씩 할당
• 스크럼 진행자가 HackMD에 스크럼 내용 실시간 정리

• 퇴근 직전(오후 6시 45분), 최대 15분
• 목적 : 스크럼에서 계획했던 할 일 얼마나 완수했는지 브리핑
• 스크럼이랑 동일한 방식

Git - 커밋 메시지 컨벤션과 커밋 메시지 템플릿을 참고하여 커밋 컨벤션을 정했다.

• 커밋 메시지 구조

type : subject

body

footer

• type 종류

• subject

  • 제목은 50자를 넘기지 않고, 한글로 통일한다.
  • 과거시제를 사용하지 않고 명령어로 작성한다.
    • "XX화면에서 버그를 수정했음" -> "XX화면 버그 수정"
    • "테스트 코드 추가했음" -> "테스트 코드 추가"
  • 제목 끝에 마침표(.)를 붙이지 않는다.
  • 제목과 본문은 띄어쓴다.

• body

  • 선택사항이며, 부연설명이 필요할 경우 작성한다.
  • 작성할 때는 "What"보다 "Why"를 적도록 한다.

• footer

  • 선택사항이며, issue tracker id를 작성할 때 사용한다.

본 내용을 참고하여 Git Flow를 프로젝트에 반영해보려고 한다.

• Master

  • 데모 가능한 상태의 브랜치.

• Develop

  • dev/ios
  • dev/web

• Feature

  • 기능별로 여러 브랜치를 생성한다. ex) feature/OAuth

• Release

  • 배포 전 실행 가능한 상태. iOS, Web의 브랜치를 합쳐서 테스트해 본다.
  • dev/ios, dev/web으로 부터 머지를 받는다.

• Hotfix

  • 계획에 없는 버그 발견 시 급하게 처리해야 할 일.

1. 각자 원본의 레포지토리를 fork한 이후, 필요한 기능을 구현할 때마다 dev 브랜치에서 feature를 생성한다.
2. feature 브랜치에서의 작업이 완료되면 원본 레포지토리의 dev 브랜치에 PR을 보낸다. feature 브랜치는 머지된 이후 삭제한다.
3. dev 브랜치에서 release 브랜치로 PR을 날리며 목요일까지 베타 버전을 만든다.
4. 목요일 저녁까지 dev 및 release 브랜치에 PR을 날린 후, 금요일 오전까지 버그를 수정한다.
5. 금요일 오전 디버깅 과정을 마친 후, release 브랜치에서 master 브랜치로 PR을 보낸다.

• PR은 최소 1일 1회 이상 하도록 한다.
• PR 구조
  • 제목 : [클래스명 #Issue번호] PR 제목
  • 내용 : issue를 어떻게 해결했는가, 해결하면서 어떤 점이 어려웠는가 등 쓰고 싶은 내용을 쓰되 코드 리뷰어들이 코멘트를 달 수 있는 화제거리가 있으면 더욱 좋을 것 같다.
• Assignees, Label, Milestone를 체크해놓는다.
• PR에 대한 approve가 최소 1개여야 merge가 가능하도록 한다.

• 이슈는 최대한 작은 단위(WBS)로 분리하여 발행한다.
  • 추후 너무 작은 단위라고 느낄 때 기능 단위로 합치도록 한다.
• 매주 마일스톤을 새롭게 생성하여 주 단위로 처리해야 할 이슈들을 구분하고, 기능 목록을 각자 할 일 단위로 쪼개서 관리해야 한다.

일단 우리는 하드워커다.(아무도 강요 안함) 다들 회의실을 떠나지 않고 남아있을 예정이고, 자유롭게 이야기하며 개발할 계획이다👍