협업 전략

작업 순서

1. 마일스톤 생성 혹은 선택
2. Github 이슈 생성
3. 브랜치 생성 및 Github 이슈 링크
4. Pull Request 추가로 작업을 진행

마일스톤

매주 수, 금요일에 upstream 에 PR 을 올리기 위한 마일스톤을 작업하기 전에 생성깃 이슈 추가 시에 마일스톤을 태그 (프로젝트 기간 동안 프론트엔드, 백엔드 각각 마일스톤을 4개씩 생성)

Git Issue Template

## Github 이슈 규칙 브랜치를 생성하기 전에 먼저 Github 이슈에 작업사항을 올리기

Title: [android/backend] 스프링 프로젝트 생성

구현/수정 사항에 대한 요약

- [X] 세부 구현 사항 1
- [ ] 세부 구현 사항 2
- [ ] 세부 구현 사항 3
- ...

+ Assignee
+ Labels
+ Projects
+ Milestone

브랜치 규칙

feature 브랜치 생성 시 [android/be]/feature/#{ISSUE_NUMBER}-FEATURE_NAME 와 같이 브랜치를 생성 예시) [android/be]/feature/#1-spring_initializr

• prefix : commit message와 유사하게 작성
• ex. android/feature/#86-card_add_in_history

커밋 규칙

아래 링크의 컨벤션에 따라 커밋 메시지를 작성

http://karma-runner.github.io/5.0/dev/git-commit-msg.html

예시 : feat/1: spring initializr 추가

Commit Template

feat: [#ISSUE_NUMBER] spring initializr 추가

(body 는 작업 내에 세부 구현 사항이 있는 경우에만 작성)
- 세부 구현사항 1
- 세부 구현사항 2
- 세부 구현사항 3
...

(footer 는 작성하지 않음)

** 타입 구분

위 링크의 컨벤션에 따라 작업사항을 아래와 같이 구분

• feat (new feature for the user, not a new feature for build script)
• fix (bug fix for the user, not a fix to a build script)
• docs (changes to the documentation)
• style (formatting, missing semi colons, etc; no production code change)
• refactor (refactoring production code, eg. renaming a variable)
• test (adding missing tests, refactoring tests; no production code change)
• chore (fix typo; updating grunt tasks etc; no production code change)
• build (Commits to build-related files)

PR 규칙

origin PR

각 feature 브랜치를 android, backend 브랜치에 merge 하기 위해 PR 생성

upstream PR

android 와 backend 브랜치에 feature 단위가 모이면 upstream 의 team-15 브랜치로 PR 생성

PR Template

origin PR Template

다른 팀원이 보고 이해할 수 있도록 구현 결과를 스크린샷/이미지로 추가

Title: [android/backend] 스프링 프로젝트 생성

PR 구현 사항에 대한 요약

- 세부 구현 사항 1
- 세부 구현 사항 2
- 세부 구현 사항 3

upstream PR Template

리뷰어가 보고 이해할 수 있도록 자세한 설명/질문 및 스크린샷/이미지로 추가

Title: [team-15][android/backend] 스프링 프로젝트 생성

PR 구현 사항에 대한 요약