Post

(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 형식으로 타 레포지토리 이슈를 참조하는 것도 가능하다.

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

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.