git commit 코드 제출 사양

1. 제출 규범을 왜 제정해야 합니까?

팀워크 개발을 할 때, 모든 사람이 코드를 제출할 때commit 메시지를 쓴다.
모든 사람은 자신의 글씨 스타일을 가지고 우리 팀의git log를 뒤적여 보면 가지각색이어서 읽기와 유지에 매우 불리하다고 할 수 있다.
일반적으로 큰 공장은 모두 자신의 제출 규범을 가지고 있는데 특히 일부 대형 개원 프로젝트에서commit 메시지는 매우 일치한다.
따라서 우리는 통일된 기준을 제정하여 팀이 일치된 코드 제출 스타일을 형성하고 업무 효율을 더욱 높여 추구하는 엔지니어가 되도록 해야 한다.

2. 업계에서 통용되는git 제출 규범에는 어떤 것들이 있습니까?

1. commitizen

AngularJS가 github에 제출한 기록은 업계의 많은 사람들에게 인정받아 점차 인용되고 있다.

형식:

type(scope) : subject

(1) type(필수): commit의 범주입니다. 다음 몇 가지 ID만 사용할 수 있습니다.

feat: 새로운 기능

fix: 버그 수정

docs: 문서 변경

style: 코드 포맷 변경

refactor: 기존의 기능 재구성

perf: 성능 최적화

test: 테스트 증가

build: grunt에서npm

로 바뀐build 도구

revert: 지난번의commit

취소

chore: 구축 과정 또는 보조 도구의 변동

(2)scope(선택 가능):commit의 영향 범위를 설명하는 데 사용한다. 예를 들어 데이터 층, 제어 층, 보기 층 등은 항목에 따라 다르다.
(3)subject(필수):commit의 간단한 설명으로 50자를 넘지 않습니다.commitizen은 Angular의 제출 규범에 따라 합격된 Commit 메시지를 작성하는 도구입니다.

설치:

전역 설치 commitizen

npm install -g commitizen

프로젝트 폴더에 들어가서 다음 명령을 실행합니다.

commitizen init cz-conventional-changelog --save --save-exact

사용:

git cz 명령 대신 git commit (git add 먼저 사용) 명령을 사용하면 다음과 같은 옵션이 나타납니다.
(1) type 선택
(2) scope(선택) 작성

? What is the scope of this change (e.g. component or file name)? (press enter to skip)
core

(3)subject 작성

? Write a short, imperative tense description of the change:
set a to b

완료, git log 명령을 실행하고 우리가 방금 제출한 commit 메시지를 보려면 다음과 같이 하십시오.

fix(core): set a to b

이점:

업계 표준에 부합

제출 과정이 더욱 규범화됨(commitizen규범 도구 사용, 스타일 통일)

스타일이 통일된commit log(type(scope):subject)

생성 가능

단점:

commitizen 도구 패키지를 설치하여 프로젝트를 더욱 크고 무겁게 (대형 소스 프로젝트에 적합)

제출 과정이 제약을 많이 받는다

일정한 학습 비용이 있다

2. git commit 템플릿 설정

단계는 다음과 같습니다.

(1) 템플릿 파일 만들기

프로젝트에서 설정합니다.git_template 파일, 내용을 사용자 정의할 수 있는 파일:

type:
scope:
subject:

(2) 템플릿 설정

다음 명령을 실행합니다.

git config commit.template .git_template //     

(3) 커밋 코드

먼저 사용git add코드 추가사용git commit템플릿에 따라 작성한 마지막git push원격으로 전송

이점:

규칙 구성 가능, 더 자유로워짐

구성 방식이 간단합니다(프로필만 추가하면 됩니다)

단점:

편의성이 떨어지고 매번vim 편집기로 템플릿을 작성해야 한다

오류가 발생하기 쉬우며 신뢰할 수 있는 검사 방법이 없음

3. 우리에 적합한git commit 제출 규범 제정

제2장에서 언급한 두 가지 업계에서 보편적으로 사용하는 규범은 모두 우리에게 완전히 적합하지 않다.
첫 번째 방식은 대형 개원 프로젝트에 적합하다. 우리도 그대로 옮기면 비교적 번거롭지만 type(scope):subject의 제출 형식을 참고할 수 있고 큰 공장과 동기화된 셈이다.두 번째 방식은 자유롭지만 번거롭지 않기 때문에 템플릿을 설정해야 한다.따라서 우리는 type(scope):subject의 제출 형식만 모방하고 도구 or 템플릿 검사를 사용하지 않으며 모두가 자각적으로 준수하면 됩니다.

서식

type: description

1. type 유형

type은 commit의 범주이며 다음과 같은 몇 가지 ID만 사용할 수 있습니다.

fix: 버그 복구

add: 새로운 기능

업데이트: 업데이트

style: 코드 포맷 변경

test: 테스트 코드 증가

revert: 지난번의commit

취소

build: 구축 도구나 구축 과정 등의 변동, 예를 들어gulp가 웹팩으로 바뀌었고 웹팩 업그레이드 등

2. description

description은 이번 제출에 대한 간단한 설명입니다.
50자를 넘지 않습니다.
설정, 수정, 증가, 삭제, 취소 등 동사로 시작하는 것을 추천합니다.

마지막으로 규칙이 정해졌으니 지켜주세요~~~