모든 사용 프로젝트는 사양에 따라 엄격하게 운영되어야 합니다. 그렇지 않으면 코드 병합, 테스트, 패키징 및 온라인과 같은 후속 작업이 허용되지 않습니다.
기본 요구 사항
모든 커밋에는 코멘트가 있어야 하며, 콘텐츠는 코멘트 형식에 따라 엄격하게 구현되어야 합니다. 콘텐츠 제출의 세분성은 합리적으로 제어되어야 합니다. 하나의 커밋에는 독립적인 기능 포인트가 포함됩니다. 하나의 제출에 여러 기능 프로젝트를 포함하는 것은 금지됩니다. 각 프로젝트의 제출 매개변수 user.name 정보를 올바르게 설정하고 인식할 수 없는 정보를 임의로 설정하지 마십시오.
버전 번호(태그)
버전 번호 명명 규칙: 주 버전 번호 부 버전 번호 개정 번호(Github 의미론적 버전 명명 규칙을 따름) 버전 번호는 마스터 브랜치만 표시하며 릴리스/롤백할 수 있는 버전 코드를 표시하는 데 사용됩니다. master 태그를 표시한다는 것은 태그를 프로덕션 환경에 공개할 수 있다는 의미입니다. 마스터 브랜치 코드의 모든 업데이트(병합)에는 버전 번호가 표시되어야 합니다. 프로젝트 관리자만이 병합하고 버전 번호를 표시할 권한이 있습니다. 마스터 브랜치.
프로젝트 권한
브라우저(게스트)는 코드 브라우즈만 가능하며 푸시, 풀 리퀘스트 등 모든 쓰기 권한은 가지고 있지 않으며, 개발자(개발자)는 브라우징, 메인이 아닌 브랜치 푸시, 풀 리퀘스트 작업지시 제출 등의 권한을 가지고 있습니다. Master)는 Git 프로젝트를 생성하고 관리할 수 있는 권한을 가지며, 브랜치 및 코드 병합, 마스터에 버전 번호 태그 등을 포함합니다.
지점 이용
모든 Git 프로젝트에는 위의 모든 분기 유형이 포함되어 있습니다. 마스터 브랜치와 개발 브랜치는 보호된 브랜치로, 병합 요청만 할 수 있고 코드를 직접 제출할 수는 없습니다.
기능적 요구 사항이나 일반 버그 수정의 경우 개발에서 기능 분기를 가져오고, 온라인 긴급 문제 수정의 경우 마스터에서 핫픽스 분기를 가져오세요.
코드 제출
하나의 커밋은 문제에 대한 해결책을 나타냅니다. 큰 문제는 각각의 작은 커밋이 이해하기 쉽도록 작은 문제로 적절하게 분류됩니다.
코드 병합
개발된 브랜치에서 개발의 최신 코드를 가져와 병합하고 충돌을 해결한 다음 해당 기능 브랜치를 생성하여 개발 브랜치에 제출하고 자동으로 병합 요청을 트리거한 다음 코드 검토를 수행하고 올바른지 확인합니다. 병합하기 전에.
(각 병합 요청에는 관련 없는 기능이 포함되어서는 안 됩니다. 병합 요청이 제출된 후 승인, 거부 등을 포함하여 역학을 적시에 추적해야 합니다. 기능이 테스트 프로세스에 들어간 후 이전 기능 분기는 다음을 수행해야 합니다. 삭제될 수 있음)
댓글 형식
각 제출물에 대해 커밋 메시지에는 머리글, 본문, 바닥글의 세 부분이 포함됩니다. 그 중 Header는 필수이며, Body와 Footer는 생략 가능합니다. 어떤 부분이든 어떤 줄도 72자를 초과할 수 없습니다. 이는 자동 줄 바꿈이 모양에 영향을 미치는 것을 방지하기 위한 것입니다.
머리글
헤더 부분에는 한 줄만 있고 유형(필수), 범위(선택 사항) 및 제목(필수)의 세 가지 필드가 포함되어 있습니다.
type은 커밋의 카테고리를 기술하는데 사용되며, 다음 7가지 식별자만 허용된다.
feat: 새로운 기능(feature) 수정: 버그 수정 docs: 문서(documentation) 스타일: 형식(코드 실행에 영향을 주지 않는 변경 사항) 리팩터링(즉, 새로운 기능이나 버그 수정이 아닌 코드 변경) ) 테스트: 증가 테스트 작업: 빌드 프로세스 또는 보조 도구 변경
Scope는 데이터 레이어, 컨트롤 레이어, 뷰 레이어 등 커밋이 영향을 미치는 범위를 설명하는 데 사용되며 프로젝트에 따라 다릅니다. 제목은 커밋 목적에 대한 간단한 설명으로, 50자 이내입니다. 동사로 시작하여 Change나 Change가 아닌 Change 등의 1인칭 현재시제를 사용하며, Change의 첫 글자는 소문자로 하고 마침표(.)로 끝나지 않습니다.
몸
Body 부분은 이 커밋에 대한 자세한 설명으로 여러 줄로 나눌 수 있습니다. 주목해야 할 두 가지 사항이 있습니다.
변경된 대신 변경과 같은 1인칭 현재 시제를 사용합니다.
코드 변경 동기를 설명하고 이전 동작과 비교하는 방법을 설명해야 합니다.
보행인
바닥글 부분은 다음 두 가지 상황에서만 사용됩니다.
현재 코드가 이전 버전과 호환되지 않는 경우 바닥글 섹션은 MARKING CHANGE로 시작하고 변경 내용에 대한 설명, 변경 이유 및 마이그레이션 방법이 이어집니다.
현재 커밋이 이슈에 관한 것이라면 바닥글 섹션에서 이슈를 닫을 수 있습니다.(Closes #123, #245, #992) GitHub의 이 기능은 매우 유용합니다.
돌아가는 것
특별한 경우도 있습니다. 현재 커밋이 이전 커밋을 실행 취소하는 데 사용되는 경우 revert:로 시작하고 그 뒤에 실행 취소 커밋의 헤더가 와야 합니다.