Git Commit 메시지: 50/72 형식 지정

Git Commit 메시지: 50/72 형식 지정

팀 포프는 블로그 게시물 http://www.tpope.net/node/106 에서 특정 Git commit 메시지 스타일을 주장합니다.

다음은 그가 추천하는 것에 대한 간단한 요약입니다.

• 첫 번째 줄은 50자 이하입니다.
• 그다음에 빈 줄.
• 나머지 텍스트는 72자로 묶어야 합니다.

그의 블로그 게시물은 다음과 같은 권장 사항에 대한 근거를 제공합니다(간단히 설명하자면 "50/72 포맷"이라고 부를 것입니다).

• 실제로 일부 도구는 첫 번째 줄을 제목 줄로 처리하고 두 번째 단락을 본문으로 처리합니다(이메일과 유사).
• git log에서는 줄 바꿈을 처리하지 않으므로 줄이 너무 길면 읽기가 어렵습니다.
• git format-patch --stdout커밋을 전자 메일로 변환합니다. 따라서 커밋이 이미 올바르게 포장되어 있는 경우 유용합니다.

팀이 동의할 것이라는 점을 덧붙이고 싶습니다.

• 커밋을 요약하는 작업은 기본적으로 모든 버전 관리 시스템에서 모범 사례입니다.다른 사용자(또는 나중에 사용자)가 관련 커밋을 더 빨리 찾을 수 있도록 도와줍니다.

그래서 제 질문에 몇 가지 각도가 있습니다.

• Git의 "생각의 리더" 또는 "경험이 풍부한 사용자" 중에서 50/72 포맷 스타일을 수용하는 사람은 어느 정도입니까?가끔 새로운 사용자들이 커뮤니티 관행을 모르거나 신경 쓰지 않기 때문에 이렇게 묻습니다.
• 이 포맷을 사용하지 않는 사람들에게, 다른 포맷 스타일을 사용하는 원칙적인 이유가 있습니까? ("처음 들어보는 것"이나 "상관없어요"가 아니라 장점에 대한 논쟁을 찾고 있다는 점에 유의하십시오.)
• 경험적으로 볼 때, Git 저장소의 몇 퍼센트가 이 스타일을 수용합니까? (만약 누군가 GitHub 저장소에 대한 분석을 하고 싶어한다면… 힌트, 힌트)

여기서 제 요점은 50/72 스타일을 추천하거나 다른 스타일을 격추하지 말라는 것입니다.(솔직히 말하자면, 저는 그것을 선호하지만, 다른 아이디어에는 개방적입니다.)저는 단지 사람들이 왜 다양한 Git commit 메시지 스타일을 좋아하거나 반대하는지에 대한 근거를 얻고 싶을 뿐입니다. (지금까지 언급되지 않은 사항들도 편하게 말씀해주세요.)

"요약" 줄(공식의 50)과 관련하여 리눅스 커널 문서에는 다음과 같은 내용이 있습니다.

For these reasons, the "summary" must be no more than 70-75
characters, and it must describe both what the patch changes, as well
as why the patch might be necessary.  It is challenging to be both
succinct and descriptive, but that is what a well-written summary
should do.

그렇긴 하지만, 커널 유지 관리자들은 실제로 50개 정도를 유지하려고 노력하는 것 같습니다.다음은 커널에 대한 Git 로그의 요약 행 길이에 대한 히스토그램입니다.

(전체 크기 보기)

이 그림보다 더 긴 요약 행이 있는 커밋은 관심 있는 부분을 하나의 선처럼 만들지 않고도 유지할 수 있는 경우에 따라서는 훨씬 더 깁니다).(아마도 그 데이터를 통합하기 위한 멋진 통계 기법이 있을 것입니다만, 글쎄요… :-)

원시 길이를 보려면 다음을 수행합니다.

cd /path/to/repo
git shortlog  | grep -e '^      ' | sed 's/[[:space:]]\+\(.*\)$/\1/' | awk '{print length($0)}'

또는 텍스트 기반 히스토그램:

cd /path/to/repo
git shortlog  | grep -e '^      ' | sed 's/[[:space:]]\+\(.*\)$/\1/' | awk '{lens[length($0)]++;} END {for (len in lens) print len, lens[len] }' | sort -n

"though leaders"와 관련하여: Linus는 전체 커밋 메시지에 대한 줄바꿈을 강조합니다.

[…] 우리는 특정 줄 형식의 따옴표가 있는 재료를 제외하고 단어를 표시하는 데 72자의 열을 사용합니다.

예외는 주로 "비프로스" 텍스트, 즉 컴파일러 오류 메시지와 같이 커밋을 위해 사람이 입력하지 않은 텍스트를 나타냅니다.

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

커밋 메시지는 문자 수에 따라 하드랩되지 않아야 하며 대신 줄 바꿈을 사용하여 프레젠테이션이 아닌 데이터의 일부로 생각, 단락 등을 구분해야 합니다.이 경우 "데이터"는 전달하려는 메시지이고 "프레젠테이션"은 사용자가 이를 보는 방식입니다.

저는 맨 위에 있는 요약 행 하나를 사용하고 짧게 하려고 노력하지만 임의의 숫자로 제한하지는 않습니다.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 commit 메시지 추천서의 작성자는 이전에 다양한 기기에서 다양한 최종 사용자가 사용할 소프트웨어를 작성한 적이 없다는 것이 의심스럽습니다.웹 사이트). 소프트웨어/프로그래밍의 발전에 있어 이 시점에서 하드 코딩된 프레젠테이션 정보로 데이터를 저장하는 것은 사용자 경험에 있어 좋지 않은 생각이라는 것이 잘 알려져 있기 때문입니다.

추천 타이틀의 최대 길이가 정말 50인가요?

나는 수년 동안 이것을 믿었지만, 방금 알아차렸듯이 "git commit"의 문서는 실제로 다음과 같이 말합니다.

$ 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

"50 미만"은 "49 미만"만 의미할 수 있다고 주장할 수 있습니다.

저는 특정한 스타일의 작업을 제안하는 것이 흥미롭다는 것에 동의합니다.하지만 스타일을 설정할 기회가 없는 한 일관성을 위해 수행된 작업을 따릅니다.

원하는 경우 git을 시작한 프로젝트인 리눅스 커널 커밋을 살펴보면, http://git.kernel.org/ ?p=linux/linux/git/torvalds/linux-2.6.git;a=commit;h=bca476139d2ded86be146da09b06e22548b67f3는 50/72 규칙을 따르지 않습니다.첫 번째 줄은 54자입니다.

저는 일관성이 중요하다고 말하고 싶습니다.특히 내부 네트워크에서 커밋한 사용자(user.name , user.email)를 식별할 수 있는 적절한 방법을 설정합니다.사용자@OFFICE-1-PC-10293982811111은 유용한 연락처 주소가 아닙니다.)프로젝트에 따라 커밋에서 적절한 세부 정보를 사용할 수 있도록 합니다.개발 프로세스에서 완료된 작업과 변경된 내용의 세부사항일 수 있기 때문에 이 작업을 설명하기가 어렵습니다.

git에 대한 특정 인터페이스가 특정 방식으로 커밋을 처리하기 때문에 사용자가 git을 한 가지 방식으로 사용해서는 안 된다고 생각합니다.

커밋을 찾을 수 있는 다른 방법도 있습니다.첫째로, 선우,git diff뭐가 바뀌었는지 말해줄 겁니다다음과 같은 작업도 수행할 수 있습니다.git log --pretty=format:'%T %cN %ce'합니다.git log.

언급URL : https://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting