Git 메시지 제출 및 제출: 최종 가이드

제출은 코드 트리에 대한 자체 포함 업데이트일 것입니다.개발 후 오류 수정이 도입될 수 있지만 제출은 '현재 내 작업을 저장하고 있으며 잠시 후에 계속할 것' 으로 간주해서는 안 된다. 특히 제출이 원격 저장소로 전송될 경우.
다른 한편, 제출은 코드 라이브러리에 대한 여러 가지 변경 사항을 포함해서는 안 된다.
만약 개발 과정에서 나는 두 개의 다른 모듈에서 일부 내용을 변경해야 하며, 이러한 변경은 관련이 없다면, 이러한 변경은 두 개의 다른 제출에 두어야 한다.
논리적으로 다른 변경 사항을 서로 다르게 제출한다는 것이다.
약속을 이행하는 것은 일종의 예술이다.제출이 자체적으로 포함되어 있는지 아닌지를 결정하는 좋은 방법은 개발자가 자신의 질문에 대답해야 한다. "내가 장래에 이 제출을 선택할 수 있습니까? 내가 그것을 필요로 합니까?"만약 답이 긍정적이라면 대다수는
이것은 아마도 매우 좋은 약속일 것이다.
메시지를 제출하는 것은 의미가 있을 것이다.'I'm developing foo' 와 같은 한 줄의 제출 메시지는 다른 개발자가 제출한 목적을 이해할 수 없게 합니다.최소값
메시지를 전송하는 형식은 다음과 같습니다.

Short log
(Optional pointers to external resources, such as defect tracking)
The intent of your change.
(Optional, if it's not clear from above) how your change resolves the
issues in the first part.
Tag line(s) at the end.

이것은 좋은 제출 메시지의 예이다.

foobar: Adjusted the foo setting in bar When using foobar on systems with less than a gigabyte of RAM common usage patterns often result in an Out-of-memory condition causing slowdowns and unexpected application termination.

Low-memory systems should continue to function without running into memory-starvation conditions with minimal cost to systems with more available memory. High-memory systems will be less able to use the full extent of the system, a dynamically tunable option may be best, long-term.

The foo setting in bar was decreased from X to X-50% in order to
ensure we don't exhaust all system memory with foobar threads.

Signed-off-by: Joe Developer <[email protected]>

여기에는 몇 가지 주의해야 할 일이 있다.최소 제출 메시지는 새 코드 개발과 간단한 변경에 유리하다.빈 줄은 항상 그 뒤에 있어야 한다. 그렇지 않으면 뒷처리 소프트웨어가 다른 내용과 구분하지 못할 수도 있다
텍스트를 제출합니다.
단일 짧은 로그 메시지는 변경해야 할 내용을 표시합니다.그것은 이 업무가 바뀐 주요 항목의 지표로부터 시작해서 간단한 변화 총결을 해야 한다.위의 예에서 우리는 '도구 모음에서 foo 설정을 조정합니다' 를 통해 'foobar' 항목을 변경했음을 나타냅니다.
단일 짧은 로그 메시지는git의 '제출 요약' 과 유사합니다.본 정책은 최대 노선의 길이를 규정하지 않았지만, 이를 유지하는 것을 건의합니다.
50자.그것을 전자메일의 주제로 상상해라. 너는 영원히 그 안에 너무 많은 글을 써서는 안 된다. 그렇지 않으면 수신자가 전자메일의 내용을 이해하기가 쉽지 않다.
또는 이 변경 사항을 가리키는 포인터를 포함할 수 있습니다
정정하다.수정 중인 구성 요소가 결함 형식을 지정하지 않으면 결함 정보에 대한 인용을 전체 URL로 지정하는 것을 권장합니다.일반적으로 이러한 포인터는 모든 긴 설명 앞에 있지만, 선택할 수 있는 옵션으로 긴 설명 뒤에 있을 수 있습니다.예를 들어, 이것은 버그 추적기에서 해결되지 않은 문제를 인용할 수 있는 좋은 방법일 수도 있다.그런 다음 변경 내용을 완벽하게 설명해야 합니다.
변경의 목적을 상세히 설명하고 필요하면 변경이 어떻게 문제를 해결하는지 설명한다.
마지막으로 하나 이상의 태그 행이 있어야 합니다.패치를 담당하는 모든 개발자는 서명인: 태그 줄을 추가하는 것을 책임진다.이 표지선은 패치를 작성한 사람이 추가해야 하고, 기타 표지선은
예를 들어 사람들은 패치를 서로 다른 지점에 합친다.이렇게 하면 코드 라이브러리의 업데이트를 쉽게 추적하고 누가 무엇을 했는지 확인할 수 있다.
메시지 헤더가 비어 있거나 존재하지 않거나 한 줄만 받아들일 수 없습니다.모든 변경 사항은 요약과 설명이 필요합니다.메시지를 제출하려면 수동으로 줄여야 합니다.일반적으로 정보의 줄마다 78자를 초과해서는 안 된다.이 조작을 편리하게 실행하기 위해서는
커밋 시 -m 스위치를 사용하지 않는 것이 좋습니다. 실제로 보내기만 하면 됩니다.

$ git commit

커밋 메시지를 자유롭게 작성할 수 있도록 편집기 환경 변수에 지정된 텍스트 편집기를 시작합니다(기본 편집기로 설정할 수 있음).가장 좋아하는 편집기를vim로 설정하면 다음 줄을 ~/.vimrc에 추가할 수 있습니다.

filetype plugin indent on
au FileType gitcommit set tw=72

이것은git가 메시지를 제출하는 텍스트를 지정한 72글자로 자동으로 포장합니다.vim에서 제출 메시지를 gitcommit로 정확하게 표시하는지 확인하기 위해 vi에서 다음 명령을 사용할 수 있습니다.

:set filetype?

또는 키를 저장합니다.

:se ft?

만약 어떤 이유로든 무의미한 설명을 가진 제출을 전송했다면, 이 제출들은 주 지점에 영원히 나타나지 않을 것입니다.
여기서 로컬 지점을 상호작용으로 재조정하고 가능한 경우 강제 전송을 발표하는 것은 좋은 방법이다.
최종 가이드에 대한 자세한 내용은 를 참조하십시오.