Git

Git

Branch

{날짜}_{브랜치명}으로 생성합니다.

날짜 : YYMMDD
브랜치명 : 한글 혹은 영어

Do

190730_투자기능개선
190523_investment_view

Don't

20190730_투자기능개선
투자기능개선
investment_view

Commit Message

커밋 메시지는 다음과같은 형태로 작성합니다. 첫 줄의 커밋 메시지로 변경사항을 어느정도 인지할 수 있도록 작성합니다.

{PREFIX}: 변경 사항 요약

상세 설명

#Issue, Bug, Sentry link

여기서 PREFIX는 다음 중 적절한 것을 사용합니다.

• ADD: 기능 추가
• CHG: 기능 변경
• FIX: 오류 수정
• REF: 리팩토링
• DEL: 제거

Do

ADD: 투자 시리얼라이저 추가
DEL: 투자 뷰 제거
FIX: PEP8 수정

FIX: 타입 수정  

타입 오류로 인해 발생한 장애 대응

# https://Sentry.io/issue=123

Don't

투자 뷰 추가
CHG: 로직 변경

Pull Request

제목

PR을 작성시에 다음의 양식에 맞추어 제목을 작성합니다.

• [분류] 내용, [대분류/소분류] 내용

Do

[투자] 투자 상품 목록 추가
[인프라/데이터베이스] 패키지 업그레이드

Don't

투자 상품 목록 추가

Description

• 리뷰 요청자는 리뷰어가 리뷰 요청자가 알고 있는 내용을 당연하게 알고있다라는 가정을 하지 않습니다.
• 리뷰 요청자는 리뷰어에게 변경사항과 관련된 충분한 문맥을 전달합니다.

만약 작성에 어려움을 겪고있다면 다음 항목에 대해 답변을 하는 방식으로 작성합니다.

1. 이 일이 왜 시작되었는지에 대한 설명
2. PR의 내용을 이해하기 위한 배경에 대한 설명
3. 현재의 상태와 미래에 변경되어야 할 내용에 대한 간단한 설명

Do

- 이 일은 XXX 라는 프로젝트에서 시작되었습니다.
- 이 변경사항을 이해하기 위해서는 아래 참고문서로 참조한 문서를 읽어보시면 도움이 됩니다.
- 현재는 A 라는 동작을 하고있는 상태인데 이것을 B 로 바꾸어 C 라는 효과를 기대합니다.

Don't

- XXX 프로젝트에서 C 라는 효과를 내기 위해서 변경합니다.

- A 에서 B 로 변경

Changes

• 변경되는 내용을 개별 항목으로 쪼개어 작성합니다.
• 코드의 변경사항을 최대한 전달하여 리뷰어가 코드의 변경 지점을 어느정도 예측하도록 합니다.

Do

- A 모델의 인스턴스 메서드의 주석을 수정합니다.
- B 함수의 반환값을 변경합니다.
- C 함수의 매개변수명을 적절한 이름으로 변경합니다.

Don't

- A 파일 코드 변경

Reference

• 변경사항과 관련이 있는 협업 도구들의 링크들을 제공해주세요.
• Trello 카드는 Github 연동 기능을 통해 Attach 해주세요.
• Sentry 와 관련이 있는 내용의 경우 Github 의 Issue 로 등록해주세요.
• 시각적인 변경인 경우, 스크린샷, GIF 등을 적극 활용해주세요.

PR review

Comment Label

• 리뷰어는 코멘트를 남길 때, 코멘트의 의도에 따라 적절한 라벨을 사용하여 리뷰 요청자가 코멘트의 의도를 더 잘 이해할 수 있게 합니다.
• 라벨과 코멘트 사이의 구분자의 특별한 제한은 없습니다. 편한것을 사용해주세요.

1(Request Changes)  2(Request Changes)  3(Comment)     4(Approve)      5(Approve)
:-------------------:-------------------:-------------------:-------------------:
변경 요구도 높음                                                         변경 요구도 낮음


1: 꼭 반영해주세요 (Request changes)
- 리뷰어는 변경사항이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 경우 이 라벨을 사용합니다.
- 리뷰 요청자는 이 의견을 요청을 반영합니다.
- 만약 반영하기 어려운 경우, 합리적인 의견을 통해 리뷰어를 설득해야만 합니다.

2: 적극적으로 고려해주세요 (Request changes)
- 리뷰어는 변경사항이 서비스에 중대한 오류가 발생하지는 않지만, 반영이 되었으면 하는 코멘트에 이 라벨을 사용합니다.
- 리뷰 요청자는 이 의견을 수용하거나 합리적인 의견을 들어 논의할 것을 권장합니다.

3: 웬만하면 반영해 주세요 (Comment)
- 리뷰어는 당장 반영이 되지 않아도 되지만 웬만해서 반영이 되면 좋겠다는 코멘트에 이 라벨을 사용합니다.
- 리뷰 요청자 이 의견을 수용하거나, 반영할 수 없는 이유를 들어 설명하거나, 다음에 반영할 계획을 명시적으로 표현할 것을 권장합니다.

4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
- 리뷰어는 PR 기능에 문제가 없고, 한 번 고민해 볼 만한 의견에 대해 이 라벨을 사용합니다.
- 리뷰 요청자는 이 의견에 대해서는 별도의 응답을 달지 않아도 괜찮습니다.
- 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

5: 그냥 사소한 의견입니다 (Approve)
- 리뷰어는 사소한 의견에 대해 이 라벨을 사용합니다.
- 리뷰 요청자는 이 의견에 대해 별도의 응답을 달지 않아도 괜찮습니다.

DO

p1; 이 기능은 잘못된 금액을 계산하게 됩니다.
p2) 이 코드를 이렇게 변경되는게 어떨까요
p3, 코드 구성을 이렇게하면 가독성이 높아질 것 같아요.
p4: 이런 방식으로 작성도 가능할 것 같아요.
p5. 이런 스타일도 괜찮을듯해요.