Tim Pope는 블로그 게시물에서 특정 Git 커밋 메시지 스타일을 http://www.tpope.net/node/106 에서 주장합니다
.
다음은 그가 권장하는 것에 대한 간략한 요약입니다.
- 첫 줄은 50 자 이하 여야합니다.
- 그런 다음 빈 줄.
- 나머지 텍스트는 72 자로 줄 바꿈해야합니다.
그의 블로그 게시물은 이러한 권장 사항에 대한 이론적 근거를 제공합니다 (간단히 “50/72 형식”이라고 함).
- 실제로 일부 도구는 첫 번째 줄을 제목 줄로, 두 번째 단락을 본문 (이메일과 유사)으로 취급합니다.
git log줄 바꿈을 처리하지 않으므로 행이 너무 길면 읽기가 어렵습니다.git format-patch --stdout커밋을 이메일로 변환-커밋이 이미 래핑 된 경우 도움이됩니다.
팀이 동의 할 것이라고 생각하는 점은 다음과 같습니다.
- 커밋을 요약하는 행위는 본질적으로 모든 버전 관리 시스템에서 모범 사례입니다. 다른 사람 (또는 나중에)이 관련 커밋을 더 빨리 찾을 수 있도록 도와줍니다.
그래서, 나는 내 질문에 몇 가지 각도를 가지고 있습니다 :
- Git의 “생각한 리더”또는 “경험이 풍부한 사용자”중 50/72 포맷 스타일을 수용하는 부분은 무엇입니까? 나는 새로운 사용자가 커뮤니티 관행을 모르거나 신경 쓰지 않기 때문에 이것을 묻습니다.
- 이 서식을 사용하지 않는 사람들에게는 다른 서식 스타일을 사용해야하는 원칙적인 이유가 있습니까? (내가 들어 본 적이 없다”또는“걱정하지 않는다”는 것이 아니라 장점에 대한 논쟁을 찾고 있다는 점에 유의하십시오.
- 경험적으로 말해서, Git 저장소의 몇 퍼센트가이 스타일을 수용합니까? (누군가 GitHub 리포지토리에 대한 분석을 원할 경우… 힌트, 힌트.)
여기서 요점은 50/72 스타일을 권장하거나 다른 스타일을 쏘지 않는 것입니다. (그것에 대해 공개하기 위해, 나는 그것을 선호하지만 다른 아이디어에 열려 있습니다.) 나는 사람들이 다양한 Git 커밋 메시지 스타일을 좋아하거나 반대하는 이유에 대한 이론적 근거를 얻고 싶습니다. (또한 언급되지 않은 점을 자유롭게 제기하십시오.)
답변
“요약”라인 (공식의 50)에 관해 Linux 커널 설명서 는 다음과 같이 말합니다 .
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 log의 요약 줄 길이에 대한 막대 그래프는 다음과 같습니다.
( 실제 크기로보기 )
흥미로운 부분을 한 줄처럼 보이게 만들지 않고이 줄거리보다 길게 (약간 더 긴) 요약 줄을 가진 커밋이 많이 있습니다. (아마도 그 데이터를 여기에 통합하기위한 멋진 통계 기술이 있지만 오 잘… 🙂
원시 길이를 보려면 다음을 수행하십시오.
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
답변
“생각하는 지도자”와 관련하여 : 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 커밋 메시지 추천의 저자는이 시점에서 소프트웨어 / 컴퓨팅이 진화 한 이래로 다른 디바이스 (예 : 웹 사이트)에서 다양한 최종 사용자가 소비 할 소프트웨어를 작성하지 않았다는 것이다. 하드 코딩 된 프리젠 테이션 정보와 함께 데이터를 저장하는 것은 사용자 경험이 진행되는 한 나쁜 아이디어라는 것은 잘 알려져 있습니다.
답변
특정 스타일의 작업을 제안하는 것이 흥미 롭다는 데 동의합니다. 그러나 스타일을 설정할 기회가 없으면 일관성을 위해 수행 한 작업을 따릅니다.
원하는 경우 git을 시작한 프로젝트 인 Linux Kernel Commit을 살펴보십시오. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h = bca476139d2ded86be146dae09b06e22548b67f3 이면 50/72 규칙을 따르지 않습니다. 첫 줄은 54 자입니다.
일관성이 중요하다고 말하고 싶습니다. 커밋 한 사용자를 식별 할 수있는 적절한 방법을 설정합니다 (user.name, user.email-특히 내부 네트워크에서. User @ OFFICE-1-PC-10293982811111은 유용한 연락처 주소가 아닙니다). 프로젝트에 따라 커밋에서 적절한 세부 정보를 제공하십시오. 그것이 무엇이어야하는지 말하기는 어렵습니다. 개발 프로세스에서 완료된 작업 일 수 있으며 변경된 내용에 대한 세부 정보 일 수 있습니다.
커밋을 처리하는 특정 인터페이스가 특정 방식으로 커밋을 처리하기 때문에 사용자가 git을 한 가지 방법으로 사용해야한다고 생각하지 않습니다.
커밋을 찾는 다른 방법도 있습니다. 먼저 git diff변경 내용을 알려줍니다. git log --pretty=format:'%T %cN %ce'옵션의 형식을 지정하는 것과 같은 작업을 수행 할 수도 있습니다 git log.
답변
최대 권장 타이틀 길이는 실제로 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 이하”만을 의미한다고 주장 할 수있다.