Ground Rule

Git 브랜치 전략

• 여러 전략 중 몇몇 캠퍼분들에게 익숙한 Git Flow를 사용하기로 함.

  참고 Git Flow 개념 이해하기

브랜치 네이밍

master
|\_dev
   |__dev_web
        |   \_feat/server/{기능}
        |   \_feat/client/{기능}
   |__dev_iOS
        |   \_feat/iOS/{기능}
|\_release

프로젝트 진행 절차

1. 이슈 등록
2. 로컬에 feature 브랜치 생성
3. 로컬 작업 및 커밋 & 리모트에 푸시
4. Pull Request (feature → dev_platform)
5. PR에 리뷰 (Web은 최소 2명, iOS는 최소 1명의 리뷰를 받아야함)
6. Merge (feature → dev_platform)
7. dev 브랜치로 1일 1PR
   1. Pull Request (dev_platform → dev)
   2. PR에 리뷰
   3. Merge (dev_platform → dev)
8. release 브랜치 생성 및 최종 점검 후 서버에 배포
9. Merge (release → dev, release → master)
10. master 커밋에 버전 태깅
    1. 배포 버전에 문제가 있을 시 fix 브랜치에서 작업
    2. Merge (fix → dev, fix → master)

Conflict 발생 시 절차

• Github Pull Requests에서 GUI 환경의 Resolve Conflicts를 사용하지 않는다.
  • Conflict를 해결하고 Merge까지 바로 해버리면 Conflict가 정상적으로 해결이 됐는지 보장할 수 없다.
• 그래서 우리는 로컬에서 Conflict를 해결해서 remote에 올리기로 한다.
  1. feature → dev_platform PR시 Conflict 발생
  2. 로컬의 dev_platform 브랜치를 최신 버전으로 업데이트한다. (dev_platorm: git pull origin dev_platform)
  3. 로컬의 feature 브랜치에 dev_platform을 머지한다. (feature: git merge dev_platform)
  4. Conflict이 발생하면 해결하고 Merge를 계속한다. (feature: git merge --continue)
  5. 변경 사항을 커밋하고 푸시한다.
  6. 올려뒀던 PR에 로컬에서 푸시한 커밋이 올라가고, Conflict files가 사라진다.
  7. 리뷰를 받고 Merge한다.

.gitignore 생성

• Swift, macOs, Xcode, CocoaPods, Node, react, Intellij

  https://www.toptal.com/developers/gitignore

커밋 메시지 규칙

참고 https://github.com/connect-foundation/2019-10/pull/237/commits

# [client | server | iOS] <타입>: <제목>
여기에 제목
##### 제목은 최대 50 글자까지만 입력 ############## -> |

# 본문은 아래에 작성
여기에 본문
######## 본문은 한 줄에 최대 72 글자까지만 입력 ########################### -> |

# 꼬릿말은 아래에 작성: ex) #이슈 번호

# --- COMMIT END ---
# <타입> 리스트
#   feat    : 기능 (새로운 기능)
#   fix     : 버그 (버그 수정)
#   refactor: 리팩토링
#   style   : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
#   docs    : 문서 (문서 추가, 수정, 삭제)
#   test    : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
#   chore   : 기타 변경사항 (빌드 스크립트 수정 등)
# ------------------
#     한글로!
#     제목 끝에 마침표(.) 금지
#     제목과 본문을 한 줄 띄워 분리하기
#     본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
#     본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# ------------------

이슈 템플릿

참고 https://soft.plusblog.co.kr/66

• Black Template
• Current Problems and Solutions
• Issue for Feature