GitHub에서 여러 풀 요청을 여는 방법

139

때 나는 열 풀 요청 에 대한 GitHub의를 .
마지막 요청 이후의 모든 커밋 및 모든 새 요청이이 요청에 자동으로 추가됩니다 .

어떤 커밋이 추가되고 어떤 커밋이 추가되지 않는지를 제어 할 수 없습니다.
다른 풀 요청을 열려고하면 "죄송합니다! 이미 풀 요청이 있습니다"오류가 발생합니다.

명령 줄을 엉망으로 만들지 않고 여러 풀 요청을 여는 쉬운 방법이 있습니까?

git github pull-request

— 횃불
소스

116

풀 요청 은 지점을 기반으로합니다.
여러 커밋에 대한 풀 요청을 여는 유일한 방법은 다음과 같습니다.

그들 자신의 지점 으로 분리하십시오 .
거기에서 끌어 오기 요청을여십시오.

— 미 파디
소스

3

좋아, 멋지다, 나는 그것이 주인과 함께 있다고 생각했다. 그래서 당신이 의미하는 것은 많은 분기를 생성하고 (예 : git flow features) 각각에 대해 풀 요청을 할 수 있다는 것입니다 ... 시도해보십시오!

— Ziyan Junaideen 5

8

방금 지점이 이전 커밋의 기록을 유지 했으므로 업스트림에 대한 풀 요청에는 여전히 모든 커밋이 포함됩니다.

— eel ghEEz

2

안녕하세요 @ eel-gheez, 이것에 대해 어떻게해야하는지 알아 냈습니까? 다른 지점의 변경 사항이 표시되지 않고 분리 된 PR을 만드는 방법은 무엇입니까?

— Jonathan Cross

3

이것은 문제를 해결하지 못합니다. PR을 만들려고하면 두 가지 (각 커밋이 각각 하나씩)가 비교됩니다. 내가 뭘 잘못하고 있죠?

— MERose

1

당신은 새로운 지점을 만들어야합니다 @eelghEEz, 자식 체리 - 선택 이 지점에 원하는 모든 커밋을 한 다음이 지점에서 풀 요청을합니다. 각 커밋이 이전 커밋에 의존하는 것은 git의 매우 중요한 디자인 기능이며, git의 커밋은 단순한 패치가 아니라이 전에 적용된 패치를 아는 패치로 이루어져야합니다. 그래서 diff가 여전히 동일하지만 이전 커밋에 대한 링크가 다른 새로운 커밋으로 새 브랜치를 만들어야합니다.

— MD

11

가장 쉬운 방법은 hub 명령 ( https://github.com/defunkt/hub )을 사용하는 것입니다.

풀 요청을 작성하려는 토픽 브랜치 (이 예에서는 "기능")에서 다음을 실행하면됩니다.

git pull-request

(먼저 지점을 밀어야합니다!)

그리고 GitHub에서 "YOUR_USER : feature"에 대한 새로운 풀 요청을 엽니 다.

이미 GitHub에서 이슈를 생성했다면 기존 이슈 (웹 UI로는 할 수없는 것)에 풀 요청을 첨부 할 수도 있습니다.

$ git pull-request -i 123
[ attached pull request to issue #123 ]

— 타일러 릭
소스

2

실제로 다른 브랜치를 만들지 않고도이 작업을 수행 할 수 있지만 약간의 재생이 필요합니다.
단계는 다음과 같습니다.

끌어낼 두 커밋 범위를 식별하십시오. 다음은 예를 위해 사용할 것입니다.
(기타 / 마스터) A-> B-> C-> D-> E (사용자 / 마스터)
한 번의 요청으로 B와 C를 가져오고 D & 다른 E.
풀 요청을하십시오. 왼쪽 ( "Base")을 커밋 A로합니다. 오른쪽 ( "head")에 커밋 번호 C를 입력합니다.
첫 번째 요청에 대한 설명을 작성하십시오.
다른 요청을하십시오. 기본에는 커밋 번호 C를 입력하고 헤드에는 E (사용자 / 마스터)를 입력하십시오.
설명을 작성하십시오.

내가 알다시피, 풀 요청은 커밋 C를 분기점으로 본다. 또는 뭔가.

— 리킹
소스

귀하 / 마스터로부터 커밋 번호를 추가하더라도 다른 / 마스터를 왼쪽으로 남겨 두어야합니다. 또한이 방법을 사용하면 몇 가지 변경이 더 필요한 경우 병합 요청에 새 커밋을 추가 할 수 없습니다.

— frisco

Github의 일부 정보와 달리이 답변에 대한 후속 조치를 게시했습니다. stackoverflow.com/questions/23159860

— Mark Bennett

나는 이것이 정확하게 원하는 커밋을 포함한다는 점에서 두 가지 PR이 올바르게 보이는 것을 볼 수 있습니다. 그러나 명시 적으로 말하면 병합 될 때 올바른 작업을 수행합니까? 마찬가지로 첫 번째 PR이 B & C를 다른 / 마스터로 올바르게 병합한다는 것을 알 수 있습니다. 그러나 2 차 PR이 합병 될 때 어떤 지점을 합병 할 것인지 어떻게 알 수 있습니까? (다른 / 마스터가 아닌 커밋 'C'에서 생성되었으므로) PR이 병합되는 순서는 중요합니까? (아마도 그렇게)

— Jonathan Hartley

1

처음으로 끌어 오기 요청을 만들 때 새 끌어 오기 요청에 대해 두 개의 별도 양식을 열면 병합 할 다른 분기를 가리키는 한 양식을 작성할 수 있습니다. 예를 들어, 마스터로 병합하는 요청과 테스트로 병합하는 요청을 별도로 두 개 만들 수 있습니다.

— 비니
소스

1

나는 Git과 GitHub를 처음 사용하고 OP와 같은 질문을했습니다.

OP 시점에는 사용할 수 없었던 솔루션을 찾았습니다.

상황 : 3 가지 변경 사항이 있으며 각각 이전 변경 사항을 작성하고 각각 자체 풀 요청 (PR)을 갖기를 원합니다.

문제점 : 마스터로 개발을 시도하는 첫 번째 PR을 작성할 때 모든 것이 정상적으로 보이지만 두 번째 PR을 변경하고 동일한 분기를 사용하여 병합 한 후에는 모든 변경 사항이 동일한 PR에 있습니다. .

미니 솔루션 : 새로운 지점 만들기

git branch mini_change_2
git checkout mini_change_2

이제 코드를 GitHub로 푸시하고 PR을 생성하지만 master는 아직 첫 번째 PR에서 변경 사항을 갖지 않기 때문에 mini_change_2에서 master로 Pull으로 기본 설정되어 있으므로 PR1 및 PR2의 모든 변경 사항이 포함됩니다.

최상의 솔루션 : PR2에서 병합 할 지점을 지정하십시오.

두 번째 PR을 만들 때 기본값을 그대로 사용하지 말고 mini_chnage_2를 Develop로 가져 가면 mini_change_2의 변경 사항 만 표시됩니다.

이제 mini_change_3에 새 브랜치 mini_change_3을 만들고 PR하십시오.

병합을 시작하면 문제가 발생하지만 다른 연습입니다.

— 마르크시 니치
소스