커밋 메시지의 버그 / 문제에 대한 참조가 모범 사례로 간주됩니까?

11

버그 추적기에 메모를 자동으로 쓰도록 소스 컨트롤을 설정 한 프로젝트를 진행 중입니다. 우리는 단순히 커밋 메시지에 버그 이슈 ID를 작성하고 커밋 메시지는 버그 트래커에 메모로 추가됩니다.

나는이 연습에 대한 몇 가지 단점을 볼 수 있습니다. 나중에 언젠가 소스 코드가 버그 추적 소프트웨어와 분리되는 경우 (또는보고 된 버그 / 문제는 어떻게 든 손실됩니다). 또는 누군가 커밋 기록을보고 있지만 버그 추적기에 액세스 할 수없는 경우.

내 질문은 커밋 메시지에 버그 / 이슈 참조가 좋은 습관으로 간주되는지 여부입니다. 다른 단점이 있습니까?

programming-practices version-control issue-tracking

— 기독교 P
소스

10

우리는이 관행을 채택했으며 우리에게 매우 효과적입니다. VCS (버전 제어 시스템)와 우리가 사용하는 다른 시스템 (예 : 지속적인 통합, 버그 추적기) 간의 긴밀한 통합은 매우 중요합니다. 우리가 미래에 무언가를 바꾸면 VCS와 버그 추적 시스템 사이의 링크를 포함하여 부작용을 평가해야 할 것입니다.

일반적으로 나는 이것이 좋은 습관이라고 생각합니다. 일부 추적 시스템의 경우 SVN ( Subversion)의 버그 트랙 속성 과 같은 추가 옵션 및 도구를 사용할 수 있습니다 . 이것은 상당수의 사람들이이 관행에서 가치를 본다는 것을 암시합니다.

— 맨 프레드
소스

13

실제로 다른 버그 추적기를 사용하거나 버그 추적기 데이터가 어떻게 사라지더라도 정보가 손실되지 않도록하려면 문제 ID 와 버그에 대한 간단한 설명을 모두 넣지 마십시오. 커밋 메시지?

버그 # 123 수정 : 로그인 후 앱이 다운 됨

그런 다음 커밋 기록에서 버그 추적기로의 링크가 있습니다. 버그 추적기를 사용할 수 없어야하는 경우에도이 특정 버그의 내용을 기록에서 확인할 수 있습니다.

— 기독교 스펙트
소스

실제로 그렇게하므로 커밋 히스토리를 탐색 할 때마다 버그 추적기로 전환 할 필요가 없습니다.

— Christian P

좋아, 그냥 그대로 두 겠어 IMO, 이것이 최선의 방법입니다!

— Christian Specht

1

예, 좋은 지적입니다. 어쨌든 그것은 내 가정이었습니다. 내 경험상 버그 / 이슈 ID만으로는 충분하지 않습니다. 커밋 로그를 살펴보면 여전히 각 커밋에 대한 내용, 예를 들어이 코드 변경의 광범위한 이유를 확인하려고합니다. 때로는 커밋 메시지가 기술적 인 측면에 더 많은 반면 버그 추적 시스템의 텍스트는 소프트웨어 사용자에게 더 적합합니다.

— Manfred

이것은 일반적으로 내가 일한 표준 관행이었습니다. 올바른 방법이라고 생각합니다.

— Carson63000

+1은 항상 이것을합니다! 방금 "버그 5423의 원인 일 수 있습니다"와 같은 보석으로 채워진 프로젝트를 유지 관리했습니다. 버그 추적기에 액세스 할 수 없습니다.

— Kryptic

2

이것은 매우 일반적인 관행이며 매우 편리합니다. TRAC를 사용하므로 코드 기록을 읽고 변경을 유도 한 작업으로 이동하거나 작업 기록을 읽고 코드 변경을 탐색 할 수 있습니다.

"나중에 언젠가 ..."코드를 버그 추적기와 분리하면 이전 버전 기록은 더 이상 관심이 없을 것입니다.

— 케빈 클라인
소스

2

나도이 연습을 사용하고 아주 좋은 것으로 생각합니다. 그러나 문제 ID 외에도 버그 / 기능에 대한 간단한 설명 (일반적으로 버그 추적 시스템의 제목)을 추가합니다. 버그 추적 시스템을 조회 할 필요가 없기 때문에 시간을 절약 할 수 있습니다 (변경 사항을 인식하기 때문에). 말했듯이 버그 추적 시스템을 잃어버린 경우에는 완전히 손실되지 않습니다.

— 니콜라 알부
소스