(Git) commit message 작성법 / 코드 리뷰 comment 작성법
커밋 메시지 작성 규칙
- 당신이 무엇을 끝냈는지에 대해 명령조로 작성하세요.
- 커밋 메시지를 과거형으로 작성하지 마세요.
- 커밋 메시지 제목의 첫 글자는 대문자로 적으며, 마침표는 찍지 마세요
- Clean your room
- Close the door
- Take out the trash
- Turn off the light
- 첫 줄은 50자 내로, 나머지 줄은 70자 내로 작성하세요.
- 두 번째 줄은 항상 비워둬야 합니다.
- 나머지 줄(세 번째 줄 부터)은 항상 자세하게 적어두세요.
- 관련 issue가 있다면,
[<#issue_num>] message
형식으로 작성해 커밋하면 해당 Issue와 커밋이 자동으로 양방향 링크된다. [<Repo_name>]/[<#issue_name>] message
형식으로 타 레포지토리 이슈를 참조하는 것도 가능하다.
header tag
- https://www.conventionalcommits.org/en/v1.0.0-beta.4/
https://overcome-the-limits.tistory.com/entry/%ED%98%91%EC%97%85-%ED%98%91%EC%97%85%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9D%B8-git-%EC%BB%A4%EB%B0%8B%EC%BB%A8%EB%B2%A4%EC%85%98-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0
코드 리뷰 comment 작성
- 코드 리뷰는 위아래가 없다는 마음 가짐으로
- 리뷰 들어온 부분 수정 및 commit
- commit history에서 수정한거 diff 뜨는 URL 복사
- 대댓글로 “Done in [URL]”
- 자동으로 comment 단 사람에게 메일 간다.
- http://tech.kakao.com/2016/02/04/code-review/
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된 상태를 가정하고 빌드를 진행해볼 수 있다는 점이다.
브랜치 전략 비교
정석 git flow
main, hotfix, release, dev, feature
- 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/
- 좀 복잡해보이지만 특별한 단점이 없다.
release 없는 git flow
card’s method.
main, hotfix, dev, feature
(+ qa-alpha, qa-beta)- 카드에서 썼었음.
- 통합이 좀 오래걸렸던 단점.
- 하지만 이건 feature를 작은 단위로 나눠서 개발하고, 인입점만 주석처리해서 merge하면 되는거라 큰 문제는 없다.
- release가 없는데 굳이 main과 dev를 나눌 필요가 있을까?
- 오히려 나눠놓으니 hotfix 후 main->dev merge 해야 하는게 귀찮았음.
- release 없다면 dev도 없어도 될 것 같다.
- 그리고 release와 dev가 없다면 == github flow 다.
dev 없는 git flow
main, hotfix, release, feature
- dev가 없는 형태인데, release가 있다면 dev가 있어야 좋을 것 같다.
- dev가 없다면 feature -> release -> main 순으로 머지가 일어나게 되는데, release에서 너무 길게 들고있게 되어 main으로의 코드 통합 주기가 너무 길어질 것 같음.
- feature를 main에서 생성 할 때도, release에서 생성 할 때도 있어 일관성이 떨어짐.
https://sihyung92.oopy.io/architecture/gitflow-vs-githubflow
github flow
realest.’s method
main, feature
- 심플한게 장점.
This post is licensed under CC BY 4.0 by the author.