회사에서 시행 할 적절한 커밋 메시지 템플릿 / 지침을 추천 할 수 있습니까? [닫은]

Git에서는 좋은 커밋 템플릿을 설정하고 시행 할 수 있습니다.

회사에서 시행하기에 적합한 커밋 템플릿 / 지침을 추천 할 수 있습니까 (논쟁이 바람직합니다)?

나는 사용한다

[Abc]: Message.

Add, Mod (ify), Ref (actoring), Fix, Rem (ove) 및 Rea (dability)를 사용하면 로그 파일을 쉽게 추출 할 수 있습니다.

예 :

Add: New function to rule the world.  
Mod: Add women factor in Domination.ruleTheWorld().  
Ref: Extract empathy stuff to an abstract class.  
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.  
Rem: freeSpeech is not used anymore.  
Rea: Removed old TODO and extra space in header.  

한 줄 이상이 있으면 가장 중요한 것으로 정렬합니다.

우리는 다음을 사용합니다.

[JIRA의 티켓 ID] : [메시지 : 수행 한 작업] 예 : ABC-123 : 지역별로 프레젠테이션을 구성하는 기능이 추가되었습니다.

이 경우 적절한 통합으로 이슈 트래커에서 파일을 변경 / 삭제 / 추가 할 수 있습니다. 그러나 ABC-123 : 완료 또는 ABC-123 : 가능하면 필터로 고정 하십시오.

하나의 간단한 규칙이 있는데, 이는 많은 SCM과 SCM과 함께 작동하는 대부분의 도구가 따르는 규칙입니다.

커밋 메시지의 첫 번째 줄은 간단한 요약이며 나머지 메시지에는 세부 정보가 포함되어 있습니다.

따라서 대부분의 도구는 첫 번째 줄만 표시하고 요청시 전체 메시지를 표시합니다.

커밋 메시지의 일반적인 오용은 변경 사항의 글 머리표 목록입니다 (첫 번째 글 머리표 만 표시됨). 또 다른 오용은 한 줄에 loooong 자세한 메시지를 작성하는 것입니다.

따라서 시행해야 할 것이 있다면 첫 번째 줄의 최대 길이라고 말합니다.

개인적으로 사용할만한 커밋 템플릿은 본 적이 없습니다. 주석은 커밋이 어떤 기능 / 버그 수정인지 또는 왜 변경되었는지에 대한 간략한 설명과 관련하여 간결하게 말해야합니다.

커밋 된 것에 대한 정보는 포함되어서는 안되며, 이것은 scm 시스템에 의해 결정될 수 있습니다. 더 많은 버그 / 기능 정보는 버그와 기능이 추적되는 곳에 속합니다.

커밋 후 버그 보고서를 업데이트 할 때 버그 보고서의 주석과 함께 커밋 개정을 언급하는 것이 좋습니다. 이 방법으로 커밋 주석에서 버그 보고서까지의 길을 찾을 수 있으며 버그 보고서에 대한 각 주석마다 커밋 된 것을 찾을 수 있지만 버그 보고서와 커밋 메시지 모두에 정보를 두어 정보를 복제하지는 않습니다.

그런 다음 파일의 개정 내역을 볼 때 내역을 설명하는 간단한 메시지가 있지만 자세한 내용은 버그 보고서 또는 작업 설명을 찾을 수있는 위치를 알 수 있습니다.

Git에서는 Git 훅으로 거의 모든 것을 시행 할 수있다 . 아이디어는 .git / hooks의 예제를 확인하십시오.

메시지의 경우 매우 일반적인 경우 해결하려는 문제와 나중에이 커밋을 찾아서 식별 할 수있는 솔루션 자체에 대한 충분한 정보를 포함하려고합니다. 대부분의 경우 문제는 버그 번호로 참조됩니다 (버그 추적 시스템과 적절히 통합). 프로세스가 통합 된 다른 시스템 (코드 검토 추적 시스템 등)이있는 경우 적절한 비트도 포함하십시오.

Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.

BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none

그러나 간단하게 유지하고 싶습니다. 그렇지 않으면 사람들은 시스템을 속이고 쓸모없는 커밋 메시지를 생성하는 방법을 찾을 것입니다.

우리는 다음을 포함하는 템플릿을 사용합니다

• 버그 / 기능 / 수정의 ID 번호
• 코드의 테스트 여부를 설명하는 예 / 아니오
• 커밋 의도에 대한 간단한 설명을위한 세부 사항 섹션

처음 두 개는 대부분 생략되지만 (때로는 세 개 모두) 실제로 큰 문제는 아닙니다.

나는 일반적으로 내가 사용하는 티켓 추적 시스템에있는 식별자 또는 첫 번째 줄로 높은 수준의 개요를 가지고 있습니다. 그런 다음 커밋의 특정 변경 사항에 대한 광고 항목 "글 머리 기호"가 있습니다. 그래서 나는 다음과 같은 것을 할 수 있었다 :

MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity

이것은 내가 가장 좋아하는 커밋 형식입니다. 그것은 직접적이고 요점입니다. 내가 이런 식으로하는 또 다른 이유는 변경 로그를 만들려면 모든 커밋 메시지를 가져 와서 변경 로그로 매우 쉽게 구문 분석 할 수 있기 때문입니다.

[ticketId] [ABC] [topicId] [WIP] 메시지 :

• ticketId-작업 저장소의 항목 ID
• ABC-추가 (기능), 수정 (버그 수정), str (구조), dep (종속성) rem (뒤로 비 호환성 / 제거), rea (가독성), ref (리팩토링)
• topicId-jenkins의 작업 선택기 및 / 또는 지점 이름 및 / 또는 gerrit의 주제 이름 일 수 있습니다.
• WIP-진행중인 작업 또는 그렇지 않은 작업 (즉, 지속적인 통합에 필요할 수 있음)
• 메시지-수정 내용

예 :
[# 452567] [추가] [menu_item] 새 항목-방명록
[# 452363] [수정] [banner_top] [WIP] 1024x300은 이제 사용할 수 있습니다
[# 452363] [수정] [banner_top] 500x200은 이제 사용할 수 있습니다
[ # 452713] [rem] [page] 왼쪽 중간 광고