답변:
Closes #1, closes #2, closes #3; rest of commit message.
closes절은 메시지 어디서나 할 수 fixes유효한 동의어입니다 :
This fixes a memory leak in foo() that closes #4,
also fixes #5 which is a duplicate.
다음 은 작동했지만 현재는 문제 # 2 및 # 3 만 참조 합니다.
Closes #1, #2, #3
Closes #1, closes #2, closes #3어떻습니까? 장황하고 중복 적입니다. 그래도 작동할까요?
Closes #1, #2, #3아십니까? closes단일 종가 대신에 종결 될 이슈의 수와 그 이후의 모든 수를 더하여 10을 쓰는 것은 우스꽝 스럽다 . : - /
해당 답변에 대한 답변과 의견은 다음 형식을 언급합니다.
# 1을 닫고 # 2를 닫고 # 3을 닫습니다. 실제 커밋 메시지
참여할 가치가있는 프로젝트가 있고 누군가가 그러한 커밋 메시지와 함께 풀 요청을 보냈다면 코드가 아무리 아름다워도 풀을 거부 할 것입니다.
이것은 내 개인적인 취향의 문제 일 수 있으며 Git 히스토리 요약을 어수선하게 만드는 커밋 메시지를 압축하는 데 사용되는 사람들에 의해 바닥에 쓰러 질 수 있지만, 다음과 같은 형식의 커밋 메시지를보고 싶습니다.
변경 사항 요약.
다음 버그
수정 : * 오류 로더 수정, # 1 수정
* 오래된 포인터 반환, # 2 수정
* GUI 요소에 새 그래픽 적용, # 3 닫힘
그는 여러 문제를 해결 하는 가장 좋은 방법을 요청했습니다 .
또한 메시지와 함께 커밋을 리포지토리의 현재 기본 브랜치가 아닌 다른 브랜치로 푸시하면 문제 만 참조됩니다. 커밋을 메인 브랜치로 푸시하면 문제가 해결됩니다. 참조 : GitHub 문제 번호에 대한 링크가 작동하지 않습니까?
때문에 그것을 참고 2013년 1월 변경되었습니다 "메시지를 커밋을 통해 문제를 닫기":
이제 Fixes #33커밋 메시지에 " " 를 입력 하면 커밋이 기본 브랜치 (일반적으로 master)에 병합 된 후에 만 33 번 이슈가 닫힙니다 .
이것은 이슈의 개설 / 종료 상태가 기본 브랜치에 매핑된다는 것을 의미하기 때문에 매우 유용합니다.
기본 브랜치에서 버그가 수정되지 않으면 문제는 계속 열려 있습니다.
수정 사항이있는 커밋이 기본 브랜치에 병합되면 문제가 자동으로 닫힙니다.다음 키워드 중 하나를 사용하여 커밋 메시지를 통해 문제를 해결할 수 있습니다.
close, closes, closed, fixes, fixed
" 다른 브랜치에있는 동안 GitHub 문제 닫기 "라는 질문에 설명 된 것처럼 이로 인해 처음에는 약간의 혼란이 발생합니다.
"키워드를 사용하여 문제 닫기" 는 문제, 태그를 닫는 방법 및 여러 문제를 닫는 방법을 설명하는 GitHub의 문서입니다.
귀하의 질문에 답하기 위해 GitHub의 답변은 다음과 같습니다.
여러 문제를 해결하려면 위의 키워드 중 하나로 각 문제 참조를 시작하십시오. 키워드가 작동하려면 참조하는 각 문제 전에 키워드를 사용해야합니다.
예를 들어, 이것은 # 34를 닫고 # 23을 닫고 닫습니다. example_user / example_repo # 42는 동일한 저장소의 문제 # 34 및 # 23을 닫고 "example_user / example_repo"저장소의 문제 # 42를 닫습니다.