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

issue / todo

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