커밋 메시지는 현재 또는 과거 시제로 작성해야합니까? [닫은]

그렇다면 어느 것이 더 좋고 더 직관적이라고 생각합니까?

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

근거를 제공해주십시오. 참고 저는 일반적인 관점에서 요청하고 있습니다. 즉, 이것을 선호하는 svn / cvs 도구 또는 프로그래밍 언어와 연관시키지 말고 모든 도구 및 프로그래밍 언어에 적용해야하거나 적용 할 수있는 것으로 생각해야합니다.

다른 개발자에게 나타나는 이러한 메시지를 생각합니다. 그들은 아직 변경 사항을 적용하지 않았고 "이 변경 세트 / 패치를 적용하면 어떤 일을하게 될까요?"라는 암시적인 질문이 있습니다. "YYY에서 XXX 버그를 수정"합니다!

다른 동사의 경우 명령으로 작성하는 것이 더 자연스러워 보이며 사전에 특정 목표가있는 경우 더 잘 작동합니다. 문자 그대로 작업이 완료되기 전에 사전 테스트와 함께 커밋 요약을 작성할 수 있습니다.

나는 그것에 엄청난 양의 무게를 두지 않지만 나에게 이것은 일관성을 유지하면서 최소한의 저항의 길입니다.

저는 개인적으로 과거형 ( "고정")을 사용합니다. 버그를 커밋 할 때까지 수정 (또는 커밋하지 않을 것)하기 때문입니다.

나는 현재 시제로 커밋 메시지를 보는 것을 선호합니다. 그런 식으로 메시지는 diff가 수행하는 작업을 설명합니다 (이 diff 또는 전체 커밋을 다른 분기로 가져올 수 있기 때문입니다). 따라서 커밋 메시지는 "한"작업을 설명하지 않습니다. 커밋 자체가 "하는"작업을 설명합니다. 따라서 현재 시제 여야합니다.

diff를 개별적으로보고 적용할지 여부를 결정한다고 상상해보십시오. 과거 시제로 제목이있는 것은 말이되지 않습니다.

IMHO 만약 당신이 문맥을 고려할 필요없이 설명 적이기를 원한다면, "Fixed"는 확실히 유일한 올바른 변형입니다.

직관성에 관해서는-변경 로그를 살펴보면 단어가 사용되는 컨텍스트를 알고 있으므로 버그가 수정되었음을 의미한다는 것을 분명히 이해할 수 있지만 단어 가이 자체로 쓰여지면 훨씬 더 빨리 잡을 것입니다. 방법 지정.

"Fixing"은 패치가 수행하는 작업을 설명하는 것뿐만 아니라 버그 상태로 해석 될 수 있으므로 IMHO는 최악의 선택입니다. 이는 작업 중이며 아직 해결되지 않았 음을 의미합니다.

Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

일반적으로 : {명령어} {영향을받는 객체} {선택적 한정자}

명령형은 패치 세트를 고려할 때 모든 사용 사례에 적합합니다.

• 여기서 무엇을 할 건가요?
• 이 패치 세트의 기능은 무엇입니까?
• 이 패치 세트가 만들어진 이유는 무엇입니까? (xxx 버그를 수정하려면 ...)
• yyy에서 xxx 버그를 수정해야합니다. 이미 이것을 수행하는 다른 브랜치에 커밋이 있습니까?

귀하의 선택에 관계없이 일관성은 가독성을 크게 향상시킵니다. 하나를 골라서 고수하십시오.

현재 시제에서 현재 커밋에 대해 쓰는 것이 좋은 생각이라고 생각합니다. 과거 시제에서 이전 커밋을 참조 할 때 더 명확 해지기 때문입니다.

나는 그것이 정말로 중요하다고 생각하지 않습니다. 목적은 다음과 같습니다.

1) 수행 중이거나 수행중인 작업을 전달하여 버그를 더 쉽게 찾고 문제를 더 쉽게 되돌릴 수 있으며 일반적으로 프로젝트를 더 쉽게 유지할 수 있습니다.

2) 어떤 티켓이 수정되었는지 전달하여 감사인이 회사에서 사용하는 경우 어떤 변경 사항이 어떤 티켓에 해당하는지 확인할 수 있습니다.

마지막으로, 이미 수정 된 경우 "Fixing"이 의미가없고 여전히 작업중인 경우 "Fixed"가 올바르지 않습니다.

" Fix bug X "는 " Fixed bug X " 보다 2 자 더 짧습니다 .
그리고 3은 " 버그 수정 X " 보다 짧습니다 .

짧은 커밋 메시지를 작성하는 관점에서 현재 시제는 가끔 / 보통 몇 글자를 저장합니까?
나는 실제로 조금 중요하다고 생각합니다. 예를 들어 Git의 권장 사항 인 50 자 미만의 첫 번째 커밋 메시지 라인에서.
또한 적은 텍스트-> 더 빨리 읽었습니까?

커밋 메시지는 커밋중인 코드를 작성한 이유를 설명합니다.

"해결 된 문제 3124"또는 "Fixes issue 3124"는이 코드가 문제 3124를 해결한다고 말했기 때문에 올바른 것 같습니다.

그러나 문법은 버그를 수정 된 것으로 표시하는 이유에 따라 달라질 수 있습니다. 커밋 한 후 버그를 수정 됨으로 표시 할 수 있다면 "Fixed"는 괜찮지 만 다른 사람이 코드를 확인한 후 버그를 수정 한 것으로 표시 할 경우 "Fixes"가 더 적절할 수 있습니다.

저는 그러한 질문에 대한 가장 중요한 대답은 다음과 같습니다. 모든 사람은 특정 프로젝트에 적합한 것을 사용해야하며 최소한 일관성을 유지해야합니다.

현재 시제를 사용할 때의 이점을 보았지만 (실제로 오픈 소스 프로젝트에서 현재 시제 메시지를 보았 기 때문에이 게시물을 우연히 발견했습니다), 저는 아마도 프로젝트에 현재 시제를 사용하지 않을 것입니다. Linux와 Git, 그리고 아마도 다른 더 큰 오픈 소스 프로젝트에 권장되는 방법이지만,이 프로젝트에 참여하지 않는 한 솔직히 신경 쓰지 않습니다.

저는 인디 개발자이고 릴리스 노트에 대한 커밋 메시지의 첫 번째 줄을 사용하는 반면 다음 줄의 설명은 구현 세부 사항에 대한 아이디어를 제공합니다. 현재 시제, 개발자 기반 접근 방식과 비교할 때 사용자 중심 워크 플로입니다. 이렇게하면 시간을 절약 할 수 있습니다. 릴리스 노트에서 사용자 지침을 제공하는 것은 매우 부자연 스럽습니다. 버그를 수정하고 기능을 추가하는 것이 제 일입니다. 저는 인디이기 때문에 시간을 절약해야합니다. 우리 팀에는 "릴리스 노트 작성자"가 없습니다.

이미 확립 된 프로젝트의 규칙을 사용하되 실용성을 유지하고 작업을 더 쉽고 빠르게 할 수있는 모든 것을하십시오.

현재 시제를 사용하는 이유 가 커미터가 한 것보다 "커밋이하는 일을 더 설명 적으로 만드는 것""Fixes XXX bug" 보다 더 합리적 이라고 생각 합니다 ."Fix XXX bug"

작은 커밋이면 현재 연속을 사용합니다.

버그 304 수정

또는

댓글 추가

큰 커밋이면 변경 로그를 더 많이 수행합니다.

• 버그 453, 657 및 324 수정
• 식 구문 추가
• Operator 클래스를 리팩터링했습니다.