브랜치 전략 - GitHub-Flow

[Bellroute]

브랜치 전략으로 GitHub-Flow를 사용한다.

1. master 브랜치 == product에 배포되는 브랜치

   • master 브랜치는 언제든지 배포 가능해야 한다
   • 무조건 pull request 하여 검토를 받는다.

2. 브랜치 생성

   • master 브랜치에서 생성해와야 한다.
   • 브랜치 이름은 한 눈에 어떤 작업을 위한 브랜치인지 알 수 있는 이름을 가져간다.

3. 커밋

   • 파일을 추가, 수정, 삭제 할때마다 커밋하여 작업 히스토리를 남긴다.
   • 작업을 진행한 이유를 다른 사람이 알 수 있도록 커밋 메세지를 남긴다.

4. pull request

   • 피드백이나 도움이 필요할 때, merge 준비가 완료된 경우 pull request를 생성한다.
   • 요청을 수락하면 변경 내용을 브랜치에 merge한다.

5. master로 merge, push 되었을 때는 즉시 배포되어야 한다.

   • master로 merge가 일어나면 자동으로 배포가 되도록 설정

[GiPyoo]

commit 컨벤션은 따로 존재하지 않나요?

[hyukjin-lee]

있으면 괜찮을 것 같네요. 어떤식으로 할까요?

[GiPyoo]

• 제목과 본문을 분리

• 한 줄로 표현 가능한 경우 제목만 써도 무방하다.

• 한글로 작성한 경우 제목은 구문형태로 영어로 작성시 명령조로 한다.

  //한글
  로그인 뷰의 버튼을 수정.
  //영어
  Fix submit button in login view

• 본문은 '어떻게' 보다 '무엇을', '왜'에 초점을 둔다.

• commit 본문에 관련 issue를 연결한다.

• 이 commit을 기준으로 issue를 닫으려고 할 때 일반 이슈의 경우는 close, 버스 픽스의 경우 fix, 문의 및 요청사항의 경우는 resolve 를 통해 닫는다.

  close #0
  fix #0
  resolve #0

이 방식은 어떤가요? 인터넷에서 찾았습니다. 컨벤션 이전에 저는 계속해서 prefix를 달고 커밋을 했었는데 위의 방식대로 해도 깔끔하고 좋을 것 같아요.

관련 페이지