Git Rule

Git Rule

브랜치 전략

• master

  • 배포 브랜치

• develop

  • 개발 브랜치
  • 해당 브랜치의 코드가 안정화되고 배포할 준비가 되면, master 브랜치로 병합

• feature

  • 기능 브랜치
  • 시작 브랜치: develop
  • 병합 브랜치: develop
  • 이름 규칙: feature/{기능 이름}
  • 기능이 완성되었을 때, develop 브랜치로 병합 후 해당 feature 브랜치 삭제

• hotfix

  • 긴급수정 브랜치
  • 시작 브랜치: master
  • 병합 브랜치: master, develop
  • 이름 규칙: hotfix/{적절한 이름}
  • 버그 해결되었을 때, 두 브랜치로 병합 후 해당 hotfix 브랜치 삭제

• 참고: https://gist.github.com/ihoneymon/a28138ee5309c73e94f9

commit 컨벤션

• why에 집중한다.
• 머리말(Type)과 파일명 등은 영어, 제목과 본문은 한글을 사용한다.
  • 머리말의 마지막에 관련된 issue 번호를 입력한다.
• 본문은 항상 작성하는 것을 지향한다.
• angular commit convention을 기본으로 따르기로 한다.
• commitlint 를 사용해서 커밋검사를 한다.
• Type
  • build: 모듈 추가 등 빌드에 영향을 끼치는 변경
  • ci: CI 도구 파일 또는 스크립트 수정
  • docs: 문서의 변경
  • style: 동작과 관련 없는 코드 스타일(;, 줄바꿈 등)
  • feat: 새로운 기능 추가
  • refactor: 코드 품질 향상
  • improve: 성능 향상
  • modify: 변수값 등 사소하지만 동작이 변경되는 코드 변경
  • add: 파일, 디렉토리 및 정적파일 등 추가
  • move: 코드, 파일, 디렉토리 및 정적파일 등 이동
  • remove: 코드, 기능, 파일, 디렉토리 및 정적파일 등 삭제
  • fix: 버그 수정
  • rename: 변수명, 파일명 변경
  • chore: 기타 잡다한 수정 및 추가, 삭제
• 예시

  feat: login
  
  유저가 원하는 닉네임을 지정할 수 있게하고 후에 랭킹, 유료 캐릭터 등 추가적인 기능을 위해 추가한다.
  
  --- 혹은
  
  move(directory): 유틸 폴더를 javascripts 폴더로 이동
  
  유틸 폴더를 javascripts 폴더로 하위 이동
  
  --- 혹은
  build: travis option 변경(#48)
  
  travis branch에 따른 행동 변경
  

issue / todo

• product backlog에서 task를 도출해 Sprint backlog로 작성한다.
  • task를 도출할 때 planning poker를 이용한다.
• issue는 Sprint backlog를 토대로 작성한다. 등록은 스프린트(한 주) 단위로 한다.

Pull Request 컨벤션

• 제목 : [브랜치이름] [task 번호[, task 번호]] [PR의 이유 한줄 요약]
  • 예시 : [feature/login] 12-1, 2, 3
  • 예시 : 매직넘버 대신 이름 사용
• 본문 : 구현에 대한 요약 / 피드백 요청사항 등..