[Git] commit message 작성법 / 코드 리뷰 comment 작성법

커밋 메시지 작성 규칙

1. 당신이 무엇을 끝냈는지에 대해 명령조로 작성하세요.
2. 커밋 메시지를 과거형으로 작성하지 마세요.
3. 커밋 메시지 제목의 첫 글자는 대문자로 적으며, 마침표는 찍지 마세요
• Clean your room
• Close the door
• Take out the trash
• Turn off the light
4. 첫 줄은 50자 내로, 나머지 줄은 70자 내로 작성하세요.
5. 두 번째 줄은 항상 비워둬야 합니다.
6. 나머지 줄(세 번째 줄 부터)은 항상 자세하게 적어두세요.

• 관련 issue가 있다면, `` [<#issue_num>] message`` 형식으로 작성해 커밋하면 해당 Issue와 커밋이 자동으로 양방향 링크된다.
• `` [<Repo_name>]/[<#issue_name>] message`` 형식으로 타 레포지토리 이슈를 참조하는 것도 가능하다.

코드 리뷰 comment 작성

• 코드 리뷰는 위아래가 없다는 마음 가짐으로
• 리뷰 들어온 부분 수정 및 commit
• commit history에서 수정한거 diff 뜨는 URL 복사
• 대댓글로 "Done in [URL]"
• 자동으로 comment 단 사람에게 메일 간다.
• http://tech.kakao.com/2016/02/04/code-review/

브랜치 전략 : Git-flow

• http://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html
• https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/
  

Git hook

• master에 바로 push 방지
• Lint 또는 Code inspector 같은 플러그인. 테스트 커버리지나 취약점 점검 같은 것
• build 자동화. Jenkins CI

feature에서 PR, 테스트 전에, dev를 당겨와서 동기화 해주는 것이 좋다.

• feature에서 작업하다가 develop이 앞으로 진행된 경우,dev를 미리 당겨서 conflict가 발생하는지 체크해 보는 것이 좋다.
• `` git merge develop -> alpha 테스트 -> PR`` 순서로 진행하는 것이 좋다.
• 커밋 메시지는 따로 변경할 필요는 없고, commit할 때 conflict발생한 파일만 커밋할 것인가? 아니면 develop에서 가져온 모든 파일을 커밋할 것인가? 선택해야 한다.
• 모든 파일을 커밋 했을 때 장점은, PR을 날린 시점에 CI에서 빌드가 진행되기 때문에 develop이랑 Merge된 상태를 가정하고 빌드를 진행해볼 수 있다는 점이다.