커밋 메시지에 closes #1 또는 fixes #1을 넣어 문제를 해결할 수 있다는 것을 알고 있습니다. 동일한 커밋 메시지에서 여러 이슈를 닫는 가장 좋은 방법은 무엇입니까?커밋 메시지로 Github에서 여러 문제 닫기
는 또한, closes보다는 fixes을 사용하는 문제에 커밋 메시지에서 링크를 생성하지 않는 것 같습니다,하지만 문제를 닫습니다 않습니다. 그게 뭐야?
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
이것은 나를 위해 작동하지 않는 것입니다. 목록의 첫 번째 항목 만 닫고 다른 항목은 닫지 않습니다. 이 게시물 이후 구문이 변경 되었습니까? 나는 그것을 봤지만, 거기에 대해 많은 도움이 될 것 같지 않습니다. –
동의. 수정 # 1, # 2는 둘 다 참조하기 위해 작동하지만 ... # 1 만 닫습니다. – waldo
@ waldo 내가 이것을 작성했을 때 이것이 효과가 있었다고 생각한다. 요즘에는'Closes # 1, Clos # 2, Closes # 3'은 어떨까? 장황하고 중복, 그래, 어쩌면 작동 할까? –
대답하고 대답 코멘트는 다음과 같은 형식 언급 :
가, # 1을 닫습니다 # 2를 닫가 # 3을 닫습니다; 실제 커밋 메시지
내가 참여할만한 가치가있는 프로젝트가 있고 다른 누군가가 그러한 커밋 메시지와 함께 풀 요청을 보낸 경우 코드가 얼마나 아름답더라도 그 풀을 거부합니다.
이것은 내 개인적인 취향의 문제 일 수 있으며 Git 히스토리 요약이 어지럽게 정리되는 메시지를 압축하는 데 사용되는 사람들에 의해 극도로 패배하게 될 수도 있지만, :
변경 사항 요약.
고정 다음 버그 :
* 수정 된 오류 로더, #에게 *는 nonstale 포인터를 반환 한
를 해결 요소를 GUI에 # 2
* 적용 새로운 그래픽을 수정, #에게 그는 질문 3
을 닫습니다 의 경우 여러 문제를 해결하는 가장 좋은 방법입니다.
또한 메시지가있는 커밋을 저장소의 현재 기본 분기가 아닌 다른 분기로 푸시하면 이슈 만 참조됩니다. 메인 브랜치에 커밋을 넣으면 문제가 해결됩니다. 참조 : January 2013 이후, "폐쇄 문제 커밋 메시지를 통해"변경된 것을
좋은 조언! :) –
방금 시도했습니다. 솔직히 말해서, 나는이게 정말 좋아! –
주 Link to GitHub issue number not working? :
을 이제 "Fixes #33"를 입력 할 때 커밋 메시지에서, 문제 (33)는 폐쇄됩니다 커밋이되면 기본 분기 (일반적으로 master)에 병합되었습니다.
이것은 문제의 열림/닫힘 상태가 기본 분기에 매핑됨을 의미하므로 매우 유용합니다.
질문에 의해 도시 된 바와 같이
버그가 기본 분기에서 수정되지 않으면 문제가 계속 열려 있습니다.
수정 사항을 적용한 커밋이 기본 분기에 병합되면 문제가 자동으로 닫힙니다.
close, closes, closed, fixes, fixed
는 "Closing a GitHub Issue while on a different branch는"이 처음에는 약간의 혼란을 야기 : 커밋 메시지를 통해
당신은 문제를 닫 이러한 키워드를 사용할 수 있습니다.
참조 http://stackoverflow.com/questions/1687262 – Krinkle