Github Rule

깃허브 사용 규칙

1. Branch Create/Merge rule

브랜치 종류

⚠️ PUSH는 feature/* 브랜치로만 할 수 있습니다. 브랜치 이름은 lower_snake_case를 사용합니다. 예) service/api_gateway

• master : 바로 시연을 할 수 있는, 버그가 없이 작동하는 최신 버전 코드입니다. 오직 release 브랜치에서 PR을 보낼 수 있습니다.
  • release : major 버전과 minor 버전 태그를 가지고 있는 브랜치입니다. develop/integration 브랜치에서 PR을 보냅니다.
    • develop/integration : develop/client 브랜치와 develop/server 브랜치를 합쳐서 release 브랜치에 올릴 수 있는 지 확인합니다.(이 브렌치는 2019.12.09 이후로 사용하지 않기로 했습니다.)
    • develop/client : 프론트엔드 개발을 위한 브랜치입니다.
      • page/* : 페이지 별 개발을 하기 위한 브랜치입니다. 페이지는 main, partners_login, reservation 등이 있습니다.
        • feature/something_1 : 각 페이지에서 feature을 분리해서 개발을 하는 브랜치입니다.
    • develop/server : 백엔드 개발을 위한 브랜치입니다.
      • service/* : 서비스 별 개발을 하기 위한 브랜치입니다. 서비스는 search, reservation, payment 등이 있습니다.
        • feature/something_2 : 각 서비스에서 feature을 분리해서 개발을 하는 브랜치입니다.

위의 규칙은 2019년 11월 25일 새로운 규칙입니다. 그렇기 때문에 기존의 코드는 develop 브랜치로 병합한 후, 리팩토링을 할 것 입니다. 2019.11.25

왜 develop/integration 브랜치를 삭제 했나요? 클라이언트 코드를 서버 브랜치가 가지고 있고, 서버 코드를 클라이언트 브랜치가 가지고 있어서 개발 서버에 바로바로 테스트하기 어려운 문제가 있었습니다. 그래서 클라이언트 브랜치에는 client 폴더만, 서버 브랜치에는 server 폴더만 관리하여 개발 서버에서 따로따로 빠르게 테스트 하려고 합니다. 2019.12.09

PR 상세 규칙

모든 PR의 assignee 에는 그 주의 프로젝트 매니저가 포함되어 있어야 합니다.
Test 코드를 통과하지 못하면 Merge를 취소합니다.

• page/* <- feature/* or service/* <- feature/*

  • feature/* 브랜치는 아침에 생성하고 마감할 때 PR을 보내고 삭제를 합니다.

• develop/client <- page/* or develop/server <- service/*

  • 팀원들의 하루 작업을 모으기 위한 PR입니다.

• release <- develop/client, develop/server

  • 개발 서버에서 원하는 시나리오대로 버그 없이 동작한다면 클라이언트 결과물과 서버 결과물을 release에 병합한 후 태그를 추가합니다.

• master <- release

  • 금요일 bug fix를 한 후 병합합니다.

태그 방법

• 태그는 v3.1 과 같이 메이저 버전과 마이너 버전으로 이루어져 있습니다.
• 마이너 버전은 release 브랜치에 클라이언트 브랜치와 서버 브랜치를 합칠 경우 1 증가 시킵니다.
• 메이저 버전은 팀 중간 점검 요일인 수요일에, 완료하기로 한 프로젝트를 만족시키면 1 증가 시킵니다. 데모데이인 금요일에 Code Freeze 후 버그를 해결하고 나면 1 증가 시킵니다.

2. Commit Rule

• 함수단위로 커밋합니다.
• 만약, 2개 이상일 경우 본문 필수!

3. Push Rule

• 작성한 Test를 통과하지 못하면 Rollback
• Test의 Coverage는 70%.
• Issue를 close하는 작업일에만 push합니다. (c1 -> c2 -> c3(close #56) -> push)
• 그 외에 팀원이 작업한 코드가 필요해 요청 시 Push할 수 있습니다.

4. Test Rule

• 함수 단위로 테스트 코드 작성.
• 테스트 라이브러리는 기본적으로 Jest 사용합니다.