Github Git Rule

github/git rule

1. git 협업 workflow

• gitflow를 사용한다.

Branch 전략

Master branch

• 배포하는 코드가 merge된다.
• 절대로 직접적으로 commit하지 않는다.
• merge되면 배포되도록 CI/CD를 구성한다.
  • master push시, 서버에 자동 배포

Develop branch

• 최초 Master branch에서 파생된다.
• 개발되는 feature들이 merge되는 브랜치다.
• 팀에서 유지되는 가장 최신의 코드이다.

Feature branch

• Feature branch는 Develop branch에서만 파생된다.
• 각기능들이 따로따로 가지게 되는 브랜치다.
• 실제 브랜치명은 '{pair시 pair-}구현하는 주제명{refactor시 -refactor}'으로 한다.
• 브랜치의 커밋들이 많아지지 않도록 feature를 잘게 나누는 것을 기본으로 한다.
  • 커밋이 많이 들어가게되는 feature는 주기적으로 Develop브랜치로 Pull Request(and merge)한뒤 다시 브랜치로 나온다.

Release branch

• Release branch는 Develop branch에서만 파생된다.
• Develop브랜치에 배포를 할 만큼 feature가 모이면 Release 브랜치로 merge한다.
• staging 서버로 배포되며 실사용 테스트를 통과하면 master로 merge를 준비한다.

Hotfix branch

• Master 브랜치에 배포된 코드가 문제가 있을 시 매우 급박하게 에러를 수정해야 할 상황에 Master 브랜치에서 Hotfix 브랜치를 파생하여 문제를 수정한 후 다시 Master 브랜치로 Merge한다.

commit rule

• 대분류
  • Feature
  • Fix
  • Docs
  • Publishing
  • Setup
  • Refactor
• 커밋 방법
  • '{대분류} : {commit 제목} issue번호'의 형태로 첫 라인을 작성한다.
  • 대분류 이외에는 한글로 작성하는 것을 원칙으로 한다.
  • 첫 라인 이후 한 개의 갭라인을 추가한다.
  • commit 내용 form
    • 상세 : 기능 구현 및 context 설명
    • 이유 : 개선과 구현 이유 설명(optional)
  • ex)

  Refactor: 모달창 컴포넌트 닫기기능 오류 수정 #12
  
  상세 : 모달내용을 포함하는 모달창 컴포넌트의 우측 상단 X모양의 버튼을 누르면 모달 백드롭과 모달창자체가 display: none이 되는 것을 hide class를 추가하는 것으로 수정
  이유 : class로 display상태를 컨트롤함으로 이후 추가적 조작이 용이해 짐
  

2. github Rule

issue

• label은 소문자로 한다.
• label은 띄어쓰기로 하는 것을 원칙으로 한다.
• 개발업무는 feature단위로 작성한다.
• 개발외의 업무는 backlog라벨을 부여하여 작성한다.

pull request

• 제목과 내용은 함수, 변수, 클래스, 에러 등 불가피한 경우가 아니면 한글로 작성한다.

project

• week 단위로 프로젝트 생성한다.
• 프로젝트의 제목은 소문자로 week(num) 방식으로 쓴다.
  • num은 두 글자를 지킨다(ex. 01, 02, 10, ...)
• 프로젝트는 to do, in progress, completed으로 구성한다.

wiki

• wiki의 페이지 제목은 첫 글자를 대문자로 한다.
• 스크럼은 wiki의 Daily Scrum에 기록한다.
  • 스크럼의 규칙은 기존의 스크럼 룰을 따른다.