GitHub : 병합 된 pull 요청 다시 열기

101

나는 약간 변경했다
풀 요청을 제출했습니다.
풀 요청이 수락되고 병합되었습니다.
버그를 발견했습니다
버그를 수정하는 동안 변경 사항이 다시 제거되었습니다.

이제 버그를 수정했으며 1 개의 추가 커밋으로 풀 요청을 다시 제출하고 싶습니다. 풀 리퀘스트를 다시 열거 나 업데이트 할 수있는 방법이 있습니까? 아니면 새 풀 리퀘스트를 생성하고 설명을 다시 입력해야합니까? Gitorious에는이 기능이 있으며 최근에 GitHub로 이동했습니다.

github merge pull-request

— 마이클 파커
소스

나는 오늘 비슷한 상황에 있었다. 즉, 기본적으로 변경 사항을 대상 분기에 병합하고 PR을 닫는 "Merge Pull Request"버튼을 사용했습니다. 나중에 테스트에서 원래 개발자가 수정하기를 원하는 버그를 발견했습니다. 이 PR에 더 많은 커밋을 추가 할 수 있도록이 PR을 다시 여는 방법을 원했지만 PR을 다시 열 수있는 버튼이 없어서 할 수 없었습니다.

— SBirthare

114

대답은 다음과 같습니다 . 할 수 없습니다.

풀 리퀘스트가 병합되고 닫히면 영구적으로 잠기고 다시 열 수 없습니다. 풀 요청이 병합되고 닫히면 변경 사항이 풀링됩니다 (병합 이전으로 강제로 밀어 넣기를 통해), 브랜치에 커밋을 추가하고 새 풀 요청을 생성하여 모든 세부 정보를 복사하고 제공 할 수 있습니다. 기록을 수동으로 저장하기위한 원래 pull 요청에 대한 링크.

향후 GitHub에 대한 멋진 기능 요청이 될 수 있습니다.

— 마이클 파커
소스

8

언제 변경되었는지는 모르겠지만 지금은 닫힌 PR에 대해 댓글을 달고 다시 열 수 있습니다.

— LB-- 2013

16

@LB, 닫히고 병합 된 PR을 다시 열 수없는 것 같습니다 .

— A Kaptur

1

실제로 할 수 있습니다. 초기 병합을 되돌 렸다고 가정하면 기본 저장소의 분기를 만들고이 새 분기에서 병합을 되 돌린 커밋을 되돌릴 수 있습니다.

— SsjCosty

7

@SsjCosty 그러나 그것은 폐쇄 및 병합 된 PR을 다시 열지 않습니다. 솔루션에 필요한 새 풀 요청을 항상 열 수 있습니다.

— 애덤 그랜트

1

"향후 GitHub에 대한 멋진 기능 요청이 될 수 있습니다." 실제로는 그렇지 않습니다. PR을 만든 후 재정의 할 수 있다면 PR을 다른 시간에 확인하는 사람들이 잠재적으로 표류 할 수 있습니다. 다른 PR을 만들고 텍스트에서 이전 PR을 "멘션"하십시오. 어떤 종류의 이정표를 참조하려면 PR이 아닌 태그를 참조하십시오.

— Scott Prive

12

방금 풀 요청을 성공적으로 다시 열었습니다.

풀 리퀘스트에 대한 코멘트
댓글 양식에 표시된 '제출 후 다시 열기'버튼을 클릭합니다.

— 팀 러벨 스미스
소스

1

나는 이것을 복제하지 못했습니다.이 동작을 확인하는 데 필요한 단계를 설명 할 수 있습니까? 나는 닫힌 풀 요청에 대해 주석을 달고 (작업하지 않았다) 닫힌 풀 요청에 대해 주석을 달고 그것이 끌어 들인 브랜치로 밀어 붙였다 (작업하지 않았다). 다른 시도가 있습니까? 풀 요청을 병합 한 다음 나중에 어떻게 든 병합 해제해야합니까?

— Michael Parker

차이점을 만드는 숨겨진 요구 사항이 무엇인지 모르겠습니다. 다음 중 하나 일 수 있습니다 (pull 요청에 대한 새 변경 사항을 제출 했음, 프로젝트 소유자의 구성원, 기타 ...)

— Tim Lovell-Smith

1

나는 지금 당신이 언급 한 모든 것을 시도했지만 여전히 그것을 볼 수 없습니다. 나는 repo 소유자입니다. Google에서 "GitHub 제출 및 다시 열기"를 검색하면이 페이지의 단일 조회가 제공됩니다. 추가 정보가 있으면 매우 도움이 될 것입니다. 풀 요청이 처음에 거부 되었습니까?

— Michael Parker

52

병합되지 않은 풀 리퀘스트로 이것을 복제 할 수 있습니다.하지만 이것이이 스레드에 관한 것이 아닙니다.

— Dan Tello

2

예, 그는 병합 된 풀이 아니라 닫힌 풀을 언급하고 있습니다.

— loujaybee

4

추가 1 커밋을 수행 한 기존 브랜치에서 새 브랜치를 파생하십시오. 거기에서 풀 요청을 제출하십시오.

— 시바 골라 팔리
소스

3

그러면 원본에 대한 기록이없는 새로운 풀 요청이 생성됩니다.

— Dave

1

이것이 내가 한 일입니다. 예, 역사는 덜 선형 적이지만 나에게는 괜찮습니다.

— possen

4

되돌리기 작업을 사용할 수 있습니다.

병합 된 PR의 모든 변경 사항을 취소하는 또 다른 풀 요청을 생성합니다.

— 윌리엄 베클
소스

이것은 가장 좋은 방법 : 아니다

— antonbormotov

2

@antonbormotov 더 나은 접근 방식을 제안 할 수 있습니까?

— William Weckl

pr을 커밋 (mA 및 mB)과 병합하여 되돌리려는 안정적인 분기를 가정 해 보겠습니다. "revert"pr을 병합 한 후 히스토리는 커밋 트리처럼 보일 것입니다 : XY-mA-mB-CD-rA-rB-EF. 변경 사항 (mA, mB)을 적용한 다음 취소 (rA, rB)하는이 모든 커밋을 기록에서 확인하려는 이유는 무엇입니까? 안정적인 분기에서 이러한 "나쁜"커밋 mA 및 mB를 리베이스하고 제거하고 기록을 깨끗하게 유지하는 것이 좋습니다. 물론 병합이 비교적 최근에 이루어 졌다면 의미가 있습니다.

— antonbormotov

1

히스토리가보기 흉해 보일뿐만 아니라, 준비가되었을 때 되 돌린 커밋을 더 이상 단순히 병합 할 수 없습니다.

— Michael

약간의 차이가있는 비슷한 시나리오가있었습니다. 검토해야 할 PR이 있고 다른 PR이 병합 될 때까지 기다려야했습니다. 그러나 나는 그것을 보지 못했고이 PR을 조기에 병합했습니다. 저는 실제로 @WilliamWeckl이 제안한 것을했습니다. 하지만 이제는 원래 만든 것과 동일한 변경 사항으로 동일한 PR을 만들고 싶습니다. 그러나 PR을 만들 때 마스터 브랜치는 차이가 나타나지 않지만 개별 파일을 볼 때 다르지만 다릅니다. 이견있는 사람?

— Vikas