커밋이 원래 생성 된 Github에서 풀 요청 찾기

풀 요청은 리포지토리에 대한 변경 또는 변경 세트에 대한 더 큰 사고를 이해하는 데 유용합니다. 풀 요청 읽기는 소스에 대한 작은 원자 적 변경 대신 논리적 변경에 대한 더 큰 그룹화를 가지므로 프로젝트를 신속하게 "확대"할 수있는 좋은 방법입니다. 쉽게 읽을 수 있도록 코드의 행을 관련 "스탠자"로 구성하는 것과 유사합니다.

파일이나 커밋을보고 있으며 커밋을 원래 생성 한 풀 요청으로 되돌릴 수있는 방법이 있는지 궁금합니다. 해당 풀 요청은 결국 병합되었지만 병합 커밋에는 필요하지 않습니다.

github로 가서 검색 창에 SHA를 입력하고 왼쪽에서 "Issues"링크를 선택하십시오.

2017 년 7 월 13 일에 업데이트 됨

Github UI를 통해이 작업을 수행하는 정말 쉬운 방법이 있습니다. UI의 브랜치에있는 커밋 목록에서 커밋을 보려면 커밋 자체에 대한 링크를 클릭하십시오. 해당 커밋에 대한 PR이 있고 지점에 직접 추가되지 않은 경우 PR 번호와 해당 지점을 나열하는 PR 링크는 페이지 상단의 커밋 메시지 바로 아래에 표시됩니다.

커밋 SHA가 있고 다른 것을 찾지 않고 파고 들지 않으려면 /commit/[commit SHA]repo url을 추가 하면 PR 링크가있는 커밋 페이지가 표시됩니다. 예를 들어, SHA가 52797a7a3b087231e4e391e11ea861569205aaf4이고 리포지토리가 https://github.com/glimmerjs/glimmer-vm 인 경우 https://github.com/glimmerjs/glimmer-vm/commit/52797a7a3b087231e4e39205eafea

git config --add remote.origin.fetch +refs/pull/*/head:refs/remotes/origin/pull/*
git fetch origin
git describe --all  --contains <COMMIT>

필요한 경우 origin풀 요청이 전송 된 github 저장소를 가리키는 원격의 이름으로 변경 하십시오. 첫 번째 명령은 지정된 원격 장치에 대해 한 번만 실행하면되고 두 번째 명령은 일반적으로 다른 업데이트를받을 때 수행됩니다.

이로 인해 git은 실제 브랜치와 함께 pull 요청에 대한 정보를 얻습니다. 그들은 같은 원격 추적 지점으로 표시됩니다 origin/pull/123. 완료되면 and 옵션 git describe과 함께 사용 하여 참조 된 커밋이있는 첫 번째 분기를 표시 할 수 있습니다 .--all--contains

그러나 찾고있는 커밋이 실제로 변경 사항이 다른 작업에 기반하거나 병합을 수행하는 사람이 일부 변경하기로 결정한 경우와 같이 풀 요청에서 수정 된 커밋 버전 인 경우에는 작동하지 않습니다.

2014 년 10 월 13 일부터는 간단합니다.

예를 들면 다음과 같습니다.

당신은 파일을 볼 수 있습니다 hakimel/reveal.js/plugin/markdown/markdown.js, 내 기여는 이제 그것이 시작된 PR # 734에 대한 참조와 함께 제공됩니다 .

이것은 커밋에서 병합 된 풀 요청 을 연결하는 것입니다 .

우리는 봤는데 커밋 페이지에 포함 된 브랜치와 태그를 포함하여 변경의 주위에 당신에게 더 많은 컨텍스트를 제공 할 수 있습니다. 이제 리포지토리의 기본 브랜치에서의 커밋은이를 소개 한 풀 요청을 보여줍니다.

풀 요청에서 커밋이 도입 된 이유에 대한 토론을보고 변경 이유에 대한 명확한 그림을 얻을 수 있습니다.

커밋 SHA를 알고 있다면 항상 커밋 페이지를 건너 뛰고 풀 요청을 직접 검색 할 수 있습니다 .

커밋 해시를 GitHub의 풀 요청 필터 필드에 넣습니다.

나는이 같은 문제가 있었고 여기에 문서화 된 pr_for_sha bash 도우미를 작성했습니다.

http://joey.aghion.com/find-the-github-pull-request-for-a-commit/

그것을 호출하면 pr_for_sha <COMMIT>브라우저에서 해당 github pull 요청 페이지가 열립니다.