당신이 버그를 고쳤다 고 생각한다고 해봅시다. 당신이 그것이 뭔가를 깨뜨린 것을 발견하고 그것을 고치기 위해 새로운 결정을 내릴 때까지 모든 것이 잠시 동안 좋았습니다. 또는 원래 픽스가 불완전하지만 이미 푸시했고 그 사이에 다른 커밋이 있음을 발견했습니다.Git에 관련된 링크 커밋
보통 커밋 메시지에는 "커밋 XXXXXXXX에 도입 된 버그를 수정합니다."와 같이 포함됩니다.
하지만 AFAIK git이 기본적으로 지원하지 않기 때문에 제 3 자 자식 도구가 인식 할 수있는 이런 종류의 일반적인 형식이 있는지 궁금합니다.
편집 :
나는 그것의 "변경-ID를"기능을 리트를 지금까지 구글입니다 수있는 가장 가까운. 우리는 우리의 회사에서 사용하는
커밋은 SHA1을 참조하십시오. 보통 도구 (예 : Github, Bitbucket, Gitlab)는이를 분석하고 해당 커밋에 연결합니다.
힌트 : 일반적으로 전체 해시를 포함 할 필요는 없습니다. 처음 6 문자로 충분합니다.
커밋 예는 here입니다.
P. Git Style Guide을 확인하고 싶을 수도 있습니다.
솔루션은 다음과 같다 : 우리는 작업 사이의 관계를 저장하지 않는
/버전 관리 시스템에 커밋,하지만 우리는 작업 추적기에 저장.
일반적으로 우리는 작업 추적기의 모든 기능/버그를 티켓으로 추적합니다. 각 티켓에는 이름 접두사와 번호가 있습니다 (예 : ProjectName-56). 티켓에 대한 작업을 시작할 때 티켓과 이름이 같은 별도의 분기를 만듭니다.
또한 해당 분기의 각 커밋 메시지는 티켓 이름으로 시작합니다 (git blame을 사용하면 해당 코드 줄과 관련된 티켓을 이해하는 데 도움이됩니다).
우리가 이슈 트래커에 저장 한 모든 작업 간의 관계, 미래에 다른 개발자에게 유용한 해설을 제공 할 수도 있습니다.
그래서 귀하의 경우에는 작업 추적기에 버그를 생성하고 ProjectName-AnotherTaskNumber를 푸시 한 후 버그가 표시되었다는 설명을 쓸 수 있습니다.
우리는 작업 추적기와 비트 버킷을 저장소로 사용하고 비트 버킷은 JIRA 티켓의 모든 ProjectName-xx 텍스트 (커밋 메시지 또는 분기)에 대한 링크를 JIRA의 티켓에 자동으로 만들고 그 반대의 경우도 마찬가지입니다. 나는 github가 github issue tracker와 동일한 통합을 가지고 있다고 생각합니다.
Google 팀에서는 형식화 된 커밋 로그 메시지에 몇 가지 주요 값이 있습니다. 동일한 버그를 수정하는 두 개의 커밋은 항상 자신의 커밋 로그 메시지에 동일한 키 값을 포함합니다. 필연적으로 몇 가지 실수가있을 것입니다. 우리는 보충 메모를 추가하기 위해'git notes '를 사용합니다. 또한 모든 버그/기능 및 관련 커밋 정보를 추적하는 추적 시스템을 갖추고 있습니다. – ElpieKay