- 사람에 대한 리뷰가 아닌, 코드에 대한 리뷰를 하자.
- 각자의 삶의 방식과 생체 리듬을 존중해주자.
- 궁금할 때는 바로 질문하자.
- 사소한 것이라도 피드백하되, 기분이 상하게 하지 말자.
- 피드백을 수용할 줄 아는 자세를 갖자.
- 밥은 먹고, 잠은 자면서 하자.
- 지각하지 말자.
- 오전 10시, 최대 15분
- 목적 : 퇴근 이후 추가 작업한 내용이 있으면 짧게 브리핑 후, 당일날 할 일 브리핑
- 사담 금지
- 스크럼 진행자가 zoom 화면공유로 타이머를 켜놓고 1인당 3분씩 할당
- 스크럼 진행자가 HackMD에 스크럼 내용 실시간 정리
- 퇴근 직전(오후 6시 45분), 최대 15분
- 목적 : 스크럼에서 계획했던 할 일 얼마나 완수했는지 브리핑
- 스크럼이랑 동일한 방식
Git - 커밋 메시지 컨벤션과 커밋 메시지 템플릿을 참고하여 커밋 컨벤션을 정했다.
- 커밋 메시지 구조
type : subject
body
footer
- type 종류
| 커밋 타입 | 설명 |
|---|---|
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| docs | 문서 수정 |
| style | 코드 포맷팅 등 코드 변경이 없는 경우 |
| refactor | 코드 리팩토링 |
| test | 테스트 코드 추가 |
| chore | 빌드 업무 수정, 패키지 매니저 수정 |
-
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
- 계획에 없는 버그 발견 시 급하게 처리해야 할 일.
- 각자 원본의 레포지토리를 fork한 이후, 필요한 기능을 구현할 때마다 dev 브랜치에서 feature를 생성한다.
- feature 브랜치에서의 작업이 완료되면 원본 레포지토리의 dev 브랜치에 PR을 보낸다. feature 브랜치는 머지된 이후 삭제한다.
- dev 브랜치에서 release 브랜치로 PR을 날리며 목요일까지 베타 버전을 만든다.
- 목요일 저녁까지 dev 및 release 브랜치에 PR을 날린 후, 금요일 오전까지 버그를 수정한다.
- 금요일 오전 디버깅 과정을 마친 후, release 브랜치에서 master 브랜치로 PR을 보낸다.
- PR은 최소 1일 1회 이상 하도록 한다.
- PR 구조
- 제목 :
[클래스명 #Issue번호] PR 제목 - 내용 : issue를 어떻게 해결했는가, 해결하면서 어떤 점이 어려웠는가 등 쓰고 싶은 내용을 쓰되 코드 리뷰어들이 코멘트를 달 수 있는 화제거리가 있으면 더욱 좋을 것 같다.
- 제목 :
- Assignees, Label, Milestone를 체크해놓는다.
- PR에 대한 approve가 최소 1개여야 merge가 가능하도록 한다.
- 이슈는 최대한 작은 단위(WBS)로 분리하여 발행한다.
- 추후 너무 작은 단위라고 느낄 때 기능 단위로 합치도록 한다.
- 매주 마일스톤을 새롭게 생성하여 주 단위로 처리해야 할 이슈들을 구분하고, 기능 목록을 각자 할 일 단위로 쪼개서 관리해야 한다.
일단 우리는 하드워커다.(아무도 강요 안함) 다들 회의실을 떠나지 않고 남아있을 예정이고, 자유롭게 이야기하며 개발할 계획이다👍