---
tags: 모헤윰
---

# Ground rule

## Commit Convention

커밋 형식

<커밋 타입>(<영역>): <커밋 메세지> <관련 이슈 리스트>,

파일명을 제외하면 영어 소문자로 작성 (한글은 무관)

ex)

- feat(be): 회원가입 API #15
- docs: api 문서 작성 #14, #16
- fix: 특정 브라우저에서 로그인이 되지 않는 버그 수정(x)
- fix: 특정 브라우저에서 로그인이 되지 않음(o)
- 버그 설명할 때 메세지 바디에 적거나 이슈로 빼서 어떤 버그가 어떻게 재현 가능한지 설명 필요

### 커밋 타입

- feat: 새로운 기능 추가
- fix: 버그 수정
- docs: 문서 관련
- refactor: 코드 리팩토링
- build: 빌드 관련 파일 수정
- test: 테스트 코드 관련
- chore: 그 외 자잘한 수정

### 커밋 영역

- fe
- be
- cicd (?)

이외에 레포지토리 전체에 해당하는 경우는 영역 표시 X


## Branch 전략

- main
- protected
- dev
- feature
- feature/{issue number}-{feature name}
- ex) feature/12-account
- fix
- fix/{issue-number}-{feature name}

1. feature, fix 단위로 브랜칭하여 개발
2. feat/fix 브랜치 리뷰 후 dev에 merge
1. 급한 PR의 경우 slack 연락 후 확인하고 바로 merge
3. 매일 오전 서로의 PR 확인 후 merge하는 과정
4. 목요일 배포 전 dev -> main

### 브랜치 과다 어떻게?

PR 후 삭제

-> GITHUB action으로 브랜치 자동 삭제 안 되나ㅏ??
delete merged branch 이런거 있을거같은데..

https://github.com/marketplace/actions/delete-merged-branch

## Issue

### 라벨링

* bug
* feature
* enhancement
* docs
* frontend
* backend

### 템플릿

#### feature

# 이슈 이름

## 이슈가 다루는 문제

## 학습 내용

## Refs.

#### bug

# 이슈 이름

## 버그 내용

스크린샷 같은거 첨부

## 버그 해결 과정

## PR

PR 확인한 사람은 리뷰어로 등록

### 라벨링

issue와 동일

### 템플릿

## 협업을 어떻게 할 것인가??
* 기능별로 개인이 fe/be다 맡기 
* 기능별로 fe쪽은 fe를 더 가져가는 식 
* 기능별로 소규모 팀을 이루어서 하기 
* 기간별로 FE, BE 몰아서 하기 
* 주마다 역할 바꿔가면서 하기 
* BE쪽에서 관리자 FE쪽 + FE쪽에서 일부 BE 맡기 
* FE/BE 나눠서 한다 
- 성익) 주마다 역할 바꿔가면서 하기
    - 바꾼 주간에는 헬퍼와 리뷰어 지정
    - 예)
        - 백성익 FE 투입 -> 헬퍼 이선민, 리뷰어 이우재
        - 막히면 5분 안에 헬퍼한테 도와달라 요청
        - PR 은 리뷰어에게 요청
        - 4주차에는 2주차에서 헬퍼, 리뷰어 변경 (헬퍼 이우재, 리뷰어 이선민)


|  | FE1 | FE2 | BE1 | BE2 |
---|---|---|---|---
Week1|이선민|이우재|김남효|백성익
Week2|이선민|**백성익**|김남효|**이우재**
Week3|이우재|**김남효**|백성익|**이선민**
Week4|이선민|이우재|김남효|백성익

헬퍼: 기존 역할 캠퍼

리뷰어: 다른 역할로 넘어간 기존 캠퍼

## 본인이 진행한 부분 문서화

### 본인의 업무 진행 상황이 다른 팀원들이 읽었을 때도 이해할 수 있도록 정리

* 자기가 작업하지 않은 부분에 대해서도 블랙박스가 생기지 않도록, 각자 분업한 부분에 대해서 구현한 방법이나 사고 과정을 정리하여 기록
* 각자 PR 보낼때 거기에 각자 고민, 해결, 진행한 부분 정리해서 보내기
> - 기존안) 한명이 취합해서 wiki에 작성 (한명이 할까? 돌아가면서 할까?)
> - 남효님) 노션을 쓰자
> - 우재님) 위키 쓰자
> - 백성익) repo 안에 docs 디렉토리 따로 .md
> - 먼저 위키를 써보고 멘토님께 피드백

### PR 단위

* ISSUE 마다 겪은 문제들 **이슈 안에 코멘트로 달기**
> - PR 종속 문제는 어떻게 해결?
> > - 곧바로 PR 요청
> > - 실무에서 어떤지 멘토님에게 질문
> > - CI 테스트 문제도 멘토님에게 질문
> > - 처음에는 코드 대격변 일어나면서 테스트 코드도 막 바뀌지 않나?  

  

## 개인의 문제상황 팀에게 공유

### 고민 혼자 30분 이상 하지 않고 물어보기

* 30분 이상 막히면 이슈 상태를 stuck으로 옮겨서 다른 사람과 같이 해결
* 이것도 이슈로 ‘왜 막혔는지’ 작성


## 코어타임 지키기

### 점심시간 이후 1시부터 7시까지 (마클있는 시간은 제외) 줌 ⇒ 카메라 켜기

* 언제든 질문하고 상의할 수 있게
* 쉬는 시간은 자유 ⇒ 쉬고 온다고 말해주기

### 코어타임 이외 시간은 자유롭게 하고 슬랙으로 소통하기


## 한주 단위 계획은 최대한 지키기 

* 안되면 주말을 쓰더라도..


## PR 머지는 전원이 확인하고 ok받으면 그때 최종 머지

* PR 내용은 다음날 데일리 스크럼때 서로 공유
* 점심식사전 (12시) 까지 최종 머지


## 개인 일정 미리 공유해주기

* 슬랙 혹은 줌


## 의사결정 충돌 발생하면 어떻게할지?

### 팀원 모두 납득 가능할 때 까지 토의

* 30분 안에
* 그래도 안되면 다수결
* 반반 동수면 사다리