git commit 메시지에 과거 또는 현재 시제를 사용해야합니까?

git commit 메시지에 과거 또는 현재 시제를 사용해야합니까? [닫은]

---

나는 한 번 읽어 그 자식 "X에 대한 테스트를 추가"예를 들어, 메시지가 필수적 현재 시제에 있어야 커밋합니다. 예를 들어 "x에 대한 추가 테스트"와 같은 과거 시제를 사용하는 것이 항상 나에게는 더 자연 스럽습니다.

최근 John Resig 커밋 이 두 메시지를 하나로 보여줍니다.

조작 테스트에서 jQuery 세트 결과를 더 조정하십시오. 또한 예상되는 테스트 결과의 순서를 수정했습니다.

상관이 있나? 어느 것을 사용해야합니까?

---

현재 시제, 명령형 커밋 메시지에 대한 선호는 Git 자체에서 온다. 에서 문서 / SubmittingPatches에 망할 놈의는 REPO :

코드베이스에 변경 명령을 내리는 것처럼 "[이 패치는 xyzzy를 frotz로 만듭니다"또는 "[I] xyzzy를 frotz로 변경했습니다"대신에 "xyzzy를 frotz로 만들기"와 같은 명령적인 분위기의 변화를 설명하십시오. 행동.

따라서 그 스타일로 작성된 많은 Git 커밋 메시지를 볼 수 있습니다. 팀이나 오픈 소스 소프트웨어에서 작업하는 경우 모든 사람이 일관성을 유지하기 위해 해당 스타일을 고수하면 도움이됩니다. 개인 프로젝트를 진행 중이고 git history를 볼 수있는 유일한 사람인 경우에도 다른 사람들과 함께 일할 때 좋은 습관을 들이기 때문에 명령적인 분위기를 사용하는 것이 도움이됩니다.

---

프로젝트는 거의 항상 과거 시제를 사용해야합니다 . 어쨌든 프로젝트는 일관성과 명확성을 위해 항상 동일한 시제를 사용해야합니다.

현재 시제를 사용한다고 주장하는 다른 주장 중 일부를 이해하지만 일반적으로 적용되지는 않습니다. 다음 글 머리 기호는 현재 시제로 쓰는 일반적인 주장과 내 대답입니다.

• 현재 시제로 글을 쓰면 커밋을 적용하는 것이 당신이 한 일이 아니라 무엇을 할 것인지 말해줍니다 .

이것이 현재 시제를 사용하려는 가장 정확한 이유이지만 올바른 스타일의 프로젝트에서만 사용됩니다. 이러한 사고 방식은 모든 커밋을 선택적 개선 사항 또는 기능으로 간주하며 특정 리포지토리에서 유지할 커밋과 거부 할 커밋을 자유롭게 결정할 수 있습니다.

이 주장은 진정으로 분산 된 프로젝트를 다루는 경우에 효과적입니다. 분산 프로젝트를 다루는 경우 아마도 오픈 소스 프로젝트를 진행하고있을 것입니다. 그리고 실제로 배포된다면 아마도 매우 큰 프로젝트 일 것입니다. 사실, 아마도 리눅스 커널이거나 Git 일 것입니다. 리눅스는 Git이 널리 퍼져 인기를 얻었을 가능성이 높기 때문에 사람들이 왜 자신의 스타일을 권위라고 생각하는지 쉽게 이해할 수 있습니다. 예, 스타일은이 두 프로젝트에서 의미가 있습니다. 또는 일반적으로 대규모 오픈 소스 분산 프로젝트 에서 작동 합니다.

즉, 소스 제어의 대부분의 프로젝트는 이와 같이 작동하지 않습니다. 대부분의 리포지토리에는 일반적으로 올바르지 않습니다. 커밋에 대한 현대적인 생각입니다. Subversion (SVN) 및 CVS 리포지토리는 이러한 유형의 리포지토리 체크인을 거의 지원할 수 없습니다. 일반적으로 통합 지점에서는 잘못된 체크인 필터링을 처리했지만 일반적으로 "선택적"또는 "사용하기 편리한 기능"으로 간주되지 않았습니다.

대부분의 시나리오에서 소스 리포지토리에 커밋 할 때이 업데이트로 변경된 사항을 설명하는 저널 항목을 작성하여 향후 다른 사람이 변경 이유를 더 쉽게 이해할 수 있도록합니다. 일반적으로 선택적인 변경 사항은 아닙니다. 프로젝트의 다른 사람들이 병합하거나 리베이스해야합니다. 당신은 같은 일기 항목을 쓰지 않는다 "친애하는 일기, 오늘은 충족 소년 그는 말한다 나에게 인사를."대신 당신은 쓰기 "내가 만난 소년과 그가 말했다 나에게 안녕하세요."

마지막으로 이러한 비 분배 프로젝트의 경우 커밋 메시지를 읽는 사람의 99.99 %가 기록을 읽는 것입니다. 기록은 과거 시제로 읽습니다. 이 커밋을 적용해야하는지 또는 지사 / 저장소에 통합해야하는지 여부를 결정할 시간의 0.01 %

• 일관성. 그것이 많은 프로젝트 (git 자체 포함)에있는 방법입니다. 또한 커밋을 생성하는 git 도구 (git merge 또는 git revert와 같은)가 수행합니다.

아니요, 버전 제어 시스템에 로그인 한 대부분의 프로젝트가 과거 시제에서 과거의 역사를 가지고 있음을 보증합니다 (참조가 없지만 현재 시제 주장이 Git 이후 새롭다는 것을 고려하면 옳습니다). 현재 시제에서 "개정"메시지 또는 커밋 메시지는 실제로 분산 된 프로젝트에서만 의미가 있습니다. 위의 첫 번째 요점을 참조하십시오.

• 사람들은 "이 코드베이스에 무슨 일이 있었는지", "이 커밋을 고르면 어떻게 될까"또는 "이 커밋으로 인해 코드베이스에 어떤 새로운 일이 일어날 지"와 같은 질문에 답하기 위해 역사를 읽습니다. 나는 미래에 합병 될 수도 있고 그렇지 않을 수도 있습니다. "

첫 번째 요점을 참조하십시오. 커밋 메시지를 읽는 사람의 99.99 %가 기록을 읽는 것입니다. 기록은 과거 시제로 읽습니다. 이 커밋을 적용해야하는지 또는 지사 / 저장소에 통합해야하는지 여부를 결정할 시간의 0.01 % 99.99 %가 0.01 %를 이깁니다.

• 일반적으로 더 짧습니다

부적절한 시제 / 문법을 사용하는 것이 더 짧기 때문에 좋은 주장을 본 적이 없습니다. 표준 50 자 메시지에 대해 평균 3 자만 저장합니다. 즉, 현재 시제 평균은 아마도 몇 글자 더 짧을 것입니다.

• 이슈 / 피처 추적기의 티켓 제목으로 커밋 이름을보다 일관되게 지정할 수 있습니다 (때로는 과거 시제를 사용하지 않지만 때로는 미래 임)

티켓은 중 현재 (예 : 앱에서 일어나고있는 무언가로 작성된 보여주는 I이 버튼을 클릭하면 잘못된 동작을), 또는 요구 사항 (예 : 텍스트가 미래에 할 수있는 뭔가 가 필요합니다 에디터에 의한 리뷰).

히스토리 (예 : 커밋 메시지)는 과거에 수행 된 것으로 작성됩니다 (예 : 문제 가 수정되었습니다).

---

365git 에 대한 자세한 설명을 작성했습니다 .

명령형, 현재 시제 사용은 약간 익숙해집니다. 내가 그것을 언급하기 시작했을 때, 그것은 저항에 부딪쳤다. 일반적으로“커밋 메시지는 내가 한 일을 기록합니다. 그러나 Git은 변경이 필요한 곳이 많은 분산 버전 관리 시스템입니다. 당신이 한 일을 말하는 메시지를 쓰는 것이 아니라; 커밋을 적용하는 방법에 대한 지침으로 이러한 메시지를 고려하십시오. 제목으로 커밋하는 대신 :

Renamed the iVars and removed the common prefix.

다음과 같이하십시오 :

Rename the iVars to remove the common prefix

어느 쪽이 당신이 한 것이 아닌 커밋을 적용 할 것인지 알려줍니다. 또한 리포지토리 기록을 보면 Git 생성 메시지도이 시제로 기록됩니다. "병합"이 아닌 "병합", "재 기반"이 아닌 "리베이스"가 동일하므로 동일한 시제로 작성하면 일관된 상태를 유지할 수 있습니다. 처음에는 이상하게 느껴지지만 (적용시 사용 가능한 평가) 의미가 있으며 결국 자연스러워집니다.

모든 것을 말했듯이 그것은 코드와 저장소입니다. 따라서 자체 지침을 설정하고 준수하십시오.

그러나이 방법으로 이동하기로 결정 git rebase -i했다면 reword 옵션을 사용하는 것이 좋습니다.

---

현재 시제 명령에 충실

• 표준을 갖는 것이 좋다
• 버그 추적기의 티켓과 자연스럽게 "구현물", "수정 물"또는 "무언가 테스트"형식입니다.

---

당신은 누구를 위해 메시지를 쓰고 있습니까? 그리고 독자는 일반적으로 소유권 이전 또는 사후 소유권 메시지를 커밋 자체로 읽는가?

나는 여기에 좋은 대답이 두 가지 관점에서 주어 졌다고 생각합니다. 어쩌면 모든 프로젝트에 가장 적합한 대답이 있다고 제안하는 데 부족할 것입니다. 분할 투표는 많은 제안을 할 수 있습니다.

즉 요약하면 :

• 다른 사람들에게 주로 전하는 메시지입니까? 일반적으로 변경을 가정하기 전에 어느 시점에서 읽습니다. 변경을 수행하는 것이 기존 코드에 어떤 영향을 미치는지 제안합니다.

• 메시지는 주로 자신 (또는 팀)에게 저널 / 레코드로 표시되지만 일반적으로 변경 사항을 가정하고 발생한 내용을 찾기 위해 다시 검색한다는 관점에서 읽습니다.

아마도 이것은 팀 / 프로젝트에 대한 동기를 어느 쪽이든 이끌어 줄 것입니다.

---

상관이 있나? 사람들은 일반적으로 메시지를 올바르게 해석하기에 충분히 똑똑합니다. 그렇지 않은 경우 어쨌든 저장소에 액세스하지 못하게해야합니다!

---

너하기에 달렸다. 커밋 메시지를 원하는대로 사용하십시오. 그러나 시간과 언어를 바꾸지 않으면 더 쉽습니다.

팀에서 개발하는 경우 논의하고 수정해야합니다.

참고 URL : https://stackoverflow.com/questions/3580013/should-i-use-past-or-present-tense-in-git-commit-messages