2022.07.01

오늘의 주제: 이슈 및 PR, 브랜치 전략

이슈 및 PR

1. 이슈 작성
2. 이슈에 대해 논의: 개발 기간 산정 및 assignee 할당
3. 기능 구현 후 PR
4. 코드 리뷰
5. 리뷰어가 모두 approve하면 PR 머지, 이슈 close

이슈에 따라 템플릿을 다르게 하자: 헤이딜러-개발팀-모두가-행복한-개발-pr관리-방법-7가지

이슈 템플릿

• 제목 컨벤션
  • prefix: [FE], [BE], [ALL]
  • suffix: 명사 예) ~ 기능 추가, ~ 기능 변경, ~ 버그 수정
• 내용
  • name, about, title, labels, assignees,
• 요구사항 (미션 요구사항처럼)
• 기한
  • 하나의 이슈에 하나의 PR
  • 이슈와 PR은 연결시키고 PR이 close되면 이슈도 close
  • 이슈를 작성 -> 이슈에 대한 기능을 구현 -> PR을 올리면서 해당 이슈 설정 -> PR merge되면 이슈 close될 수도
  • 이슈는 분야 상관없이 발견하면 ~ 문제로 바로 작성하고 prefix를 [All]로 붙인다.

한번 해보고 경험을 얘기해서 이슈관리는 다시 정리

PR 템플릿

• PR 타입
• 반영 브랜치
• 요구 사항
• 변경 로직
• 논의하고 싶은 내용

이슈 넘버 : Close #761

맨 위나 밑이나, 특정 키워드, #, number 넣으면 해당 이슈에 대한 링크를 생성한다.

딱딱하게 하지말고, 유연하게 but 템플릿은 잘 지키기

버그 템플릿

• 버그 기능
• 버그 상황 재연
  • 버그 상황 재연을 적어줘야 다른 사람이 똑같은 상황으로 확인이 가능해짐
• 기대 동작
• 현재 동작

커밋 컨벤션

################
# <타입>: <제목> 의 형식으로 제목을 아래 공백줄에 작성
# 제목은 50자 이내 / 변경사항이 "무엇"인지 명확히 작성 / 끝에 마침표 금지
# 예) feat: 로그인 기능 추가

# 바로 아래 공백은 지우지 마세요 (제목과 본문의 분리를 위함)

################
# [Optional] 본문(구체적인 내용)을 아랫줄에 작성
# 여러 줄의 메시지를 작성할 땐 "-"로 구분 (한 줄은 72자 이내)

################
# [Optional] 꼬릿말(footer)을 아랫줄에 작성 (현재 커밋과 관련된 이슈 번호 추가 등)
# 예) Refs #1

################
# feat: 새로운 기능 추가
# fix: 버그 수정
# docs: 문서 수정
# test: 테스트 코드 추가
# refactor: 코드 리팩토링
# style: 코드 의미에 영향을 주지 않는 변경사항
# chore: 빌드 부분 혹은 패키지 매니저 추가 및 수정
################

• squash merge commit도 prefix에 [FE], [BE], [ALL]을 붙인다.

---

브랜치 전략

git-flow, github-flow, gitlab-flow가 있었음.

필즈의 git-flow 경험

product <- develop <- feat1
______________ <- feat2

production 브랜치에는 오류가 없어야한다.

github-flow

간단하지만 복잡한 프로젝트에는 맞지 않아 보임.

gitlab-flow

git-flow, github-flow의 문제점을 절충한 방법. 알아보는 중.

• [gitlab-flow를 사용할 경우 지켜야할 11가지 원칙](https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/)

git-flow

가장 복잡하지만 대중적으로 사용됨. 주말에 알아볼 예정.

---

Suggestions

• 마감 기한까지 완료 못할것 같으면 최대한 빠른 시일에 얘기를 해야한다. -> 대처 가능
• 말을 끊지 않는다.
• 아이디어에 대해 부정적인 반응을 보이지 않는다.
  • 많은 아이디어를 제안할 용기를 빼앗지 말자!

---

To-Do (Due: Monday 아침)

ALL

• git-flow 공부해오기

FE

• 프로토타이핑 완성
• 프로젝트 환경설정

BE

• DB 설계해오기 (슥~ 적당히) - 객체든 테이블 관점이든 하나만 편한대로.

What’s Next…

ALL

• 팀 문화 한번 돌아보기
• git branch 전략 정하기
• 체크인 / 체크아웃 회의
  • 오늘 할 일 무엇인지 공유
  • 오늘 무엇을 했는지 공유

FE

• 기능 개발 시작
• API mocking
• 테스트 코드 작성

BE

• 환경설정하기, DB 설계
• Discussion API 기능 개발
• 고민거리
  • Mocking은 어디서?
  • DTO 반환?