[Draft] 커밋 퀄리티 & PR 팁

[arch-spatula]

글쓰기 주제

draft/git-commit

---

• [ ] PR에 200줄 초과하면 경계하기 시작합니다. 무지성 LGTM을 날릴 환경이 생깁니다.
• [ ] 코드 퀄리티에 포함된 부분 중 하나는 커밋 퀄리티입니다. 코드 커밋의 퀄리티도 장기적으로 중요합니다. 일부 개발자는 기본 중에 기본으로 보기도 합니다. 하지만 맥락에 맞게 적용하도록 합니다.

참고할 자료

• [GitHub] git commit 템플릿 사용하여 commit message convention 준수하기
• 좋은 git commit 메시지를 위한 영어 사전

[arch-spatula]

# <타입> : <제목> 형식으로 작성하며 제목은 최대 50글자 정도로만 입력
# 제목을 아랫줄에 작성, 제목 끝에 마침표 금지, 무엇을 했는지 명확하게 작성

################
# 본문(추가 설명)을 아랫줄에 작성

################
# 꼬릿말(footer)을 아랫줄에 작성 (관련된 이슈 번호 등 추가)

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

[arch-spatula]

사람에 따라 다릅니다. 400줄 이하까지 권장하는 경우도 있습니다.

PR의 사이즈에 대한 요점은 단순합니다. 읽고 검증해야 할 면적을 줄이는 것입니다.

[arch-spatula]

1일 1PR로 평소 자주 코드의 싱크를 맞추라고 합니다.

초보과 봤을 때 괜찮다는 생각이 듭니다. merge conflict가 발생해도 규모가 작을 가능성도 커보입니다.

초보에 약간 진화하면 이런 생각을 합니다. merge conflict가 발생한다는 것 자체가 그 엔지니어의 자질을 의심해봐야 한다는 의견을 갖습니다. 그리고 아주 긴 브랜치 2개에 과감하게 rebase하는 능력은 기본 중 기본이라고 봅니다.

하지만 다시 초보처럼 돌아와서 평소 작은 규모로 PR을 빠르게 하는 것이 좋다고 보게됩니다. 이유는 PR 사이즈가 너무 크면 아무도(본인도 포함해서) 안 읽습니다. 팀원이 PR을 읽고 코드를 계속 개선하게 만들려면 다시 1일 1PR을 하게 만듭니다.