프레젠테이션과 데이터를 분리하면 커밋 메시지가 여기에 전달됩니다.

커밋 메시지에서 하드 포장해서는 안 어떤 글자 수 대신 줄 바꿈은 데이터가 아닌 프리젠 테이션의 일부로 등 별도 생각, 단락에 사용되어야한다. 이 경우 “데이터”는 사용자가 만나고 자하는 메시지이고 “표시”는 사용자가이를 보는 방식입니다.

상단에 단일 요약 줄을 사용하고 짧게 유지하려고하지만 임의의 숫자로 제한하지 않습니다. Git이 실제로 메시지와 별도의 엔티티로 요약 메시지를 저장하는 방법을 제공했지만 훨씬 더 좋을 것입니다.하지만 해킹 할 필요가 없으므로 첫 번째 줄 바꿈을 구분 기호로 사용합니다 (행운 적으로 많은 도구 지원 데이터를 분리하는 수단).

메시지 자체에 줄 바꿈은 데이터에서 의미있는 것을 나타냅니다. 줄 바꿈 하나는 목록의 시작 / 중단을 나타내고, 줄 바꿈 두 개는 새로운 생각 / 아이디어를 나타냅니다.

This is a summary line, try to keep it short and end with a line break.
This is a thought, perhaps an explanation of what I have done in human readable format.  It may be complex and long consisting of several sentences that describe my work in essay format.  It is not up to me to decide now (at author time) how the user is going to consume this data.

Two line breaks separate these two thoughts.  The user may be reading this on a phone or a wide screen monitor.  Have you ever tried to read 72 character wrapped text on a device that only displays 60 characters across?  It is a truly painful experience.  Also, the opening sentence of this paragraph (assuming essay style format) should be an intro into the paragraph so if a tool chooses it may want to not auto-wrap and let you just see the start of each paragraph.  Again, it is up to the presentation tool not me (a random author at some point in history) to try to force my particular formatting down everyone else's throat.

Just as an example, here is a list of points:
* Point 1.
* Point 2.
* Point 3.

텍스트를 부드럽게 감싸는 뷰어의 모양은 다음과 같습니다.

이것은 요약 줄이므로 줄을 짧게 유지하고 줄 바꿈으로 끝내십시오.

이것은 아마도 인간이 읽을 수있는 형식으로 수행 한 것에 대한 설명 일 것입니다. 내 작품을 에세이 형식으로 설명하는 여러 문장으로 구성되어 복잡하고 오래 걸릴 수 있습니다. 사용자가이 데이터를 어떻게 사용할 것인지 지금 (작성 시점에) 결정하는 것은 나에게 달려 있지 않습니다.

두 줄 바꿈은이 두 생각을 분리합니다. 사용자가 전화 나 와이드 스크린 모니터에서이 내용을 읽었을 수 있습니다. 60 자만 표시하는 장치에서 72 자 랩핑 텍스트를 읽으려고 한 적이 있습니까? 정말 고통스러운 경험입니다. 또한이 단락의 시작 문장 (에세이 스타일 형식으로 가정)은 단락에 대한 소개 여야하므로 도구를 선택하면 자동 줄 바꿈하지 않고 각 단락의 시작 부분 만 보도록 할 수 있습니다. 다시 말하지만, 내 특정 형식을 다른 사람의 목 아래로 내밀어내는 것은 내가 아닌 프레젠테이션 도구에 달려 있습니다.

예를 들어 다음은 포인트 목록입니다.
* 포인트 1
* 포인트 2
* 포인트 3.

내 생각에 당신이 링크 한 Git 커밋 메시지 추천의 저자는이 시점에서 소프트웨어 / 컴퓨팅이 진화 한 이래로 다른 디바이스 (예 : 웹 사이트)에서 다양한 최종 사용자가 소비 할 소프트웨어를 작성하지 않았다는 것이다. 하드 코딩 된 프리젠 테이션 정보와 함께 데이터를 저장하는 것은 사용자 경험이 진행되는 한 나쁜 아이디어라는 것은 잘 알려져 있습니다.

답변

$ git help commit | grep -C 1 50
      Though not required, it’s a good idea to begin the commit message with
      a single short (less than 50 character) line summarizing the change,
      followed by a blank line and then a more thorough description. The text

$  git version
git version 2.11.0