Github에서 풀 요청을 기본값이 아닌 다른 브랜치에 병합
답변:
2016 년 8 월 15 일부터 GitHub에서는 GUI를 통해 pull 요청의 대상 분기를 변경할 수 있습니다. Edit제목 옆을 클릭 한 다음 드롭 다운에서 분기를 선택합니다.
이제 열린 풀 요청의 기본 분기를 변경할 수 있습니다. 풀 요청을 생성 한 후 풀 요청의 변경 사항이 다른 브랜치와 비교되도록 기본 브랜치를 수정할 수 있습니다. 올바른 기본 브랜치로 새 요청을 여는 대신 원래 풀 리퀘스트의 기본 브랜치를 변경함으로써 귀중한 작업과 토론을 유지할 수 있습니다.
제출자는 풀 요청을 발행 할 때이를 변경할 수 있지만 일단 발행하면 변경할 수 없습니다.
반면에, 수동으로 브랜치와 푸시를 병합 할 수 있는데, 잘못 타겟팅 된 풀 요청에 대해 반 정기적으로 수행합니다.
풀 리퀘스트의 구성 요소로 작업하는 데 hubgem이 도움 이 될 수 있습니다 .
이 gem은 다음과 같은 수동 프로세스를 마무리합니다.
git merge --no-ff ...@GuillermoMansilla가 그의 답변에서 언급 한대로 사용 하는 것이 좋습니다 .
다른 답변에서 언급 한 허브 gem을 사용하는 대안 은 명령 줄을 사용하여 로컬 풀 요청을 병합 하는 것입니다.
$ git fetch origin
$ git checkout *target_branch*
$ git merge pr/XXX
$ git push origin *target_branch*
위의 명령은 .git/config파일에 다음 줄을 먼저 추가 한 경우에만 직접 작동 합니다.
fetch = +refs/pull/*/head:refs/remotes/symbolic_name_origin_or_upstream/pr/*
그것은 당신이 모든 풀 리퀘스트 를 다운로드 할 수있게 해준다 . 거대한 리포지토리에는 바람직하지 않을 수 있으므로 GitHub는 git fetch origin pull/ID/head:BRANCHNAME구문 을 특징으로하는 지침을 수정하여 구성 파일의 수정을 방지하고 해당 단일 풀 요청 만 다운로드합니다.
자신의 것이 아니기 때문에 기존 풀 요청을 변경할 수는 없지만 관련 소스 저장소가 여전히 존재하면 쉽게 새 요청을 만들 수 있습니다. 예, 다른 사람의 것이더라도 가능합니다.
제출자의 리포지토리로 이동 한 다음 동일한 커밋을 사용하여 리포지토리에 새 풀 요청을 생성하지만 올바른 대상 브랜치를 올바르게 설정했는지 확인합니다.
그런 다음 자신의 저장소로 돌아가 새로운 풀 요청을 수락합니다. 짜잔!
Daniel Pittman의 솔루션에는 아무런 문제가 없지만 이러한 병합을 "빨리 감기 없음"으로 간주합니다. 즉, 3 단계를 다음과 같이 변경합니다.
git checkout ${target_branch} && git merge --no-ff ${remote}/${branch}
를 사용 --no-ff하면 기록을 더 쉽게 읽을 수 있습니다. $n커밋이에서 나왔다고 명확하게 말하고 $branch해당 브랜치에서 수행 한 작업을 되돌려 야하는 경우 생활이 더 쉬워집니다.
또한 eoinoc의 질문에 답하고 추가 팁을 제공하려면 :
병합을 수행하면 git cli가 메시지를 작성하라는 메시지를 표시합니다. 일반적으로 다음과 같은 일반적인 메시지가 표시됩니다.
원격 추적 분기 '사용자 / 자신의 분기'를 분기에 병합
해당 메시지를 편집하고 풀 요청 번호에 대한 참조를 포함해야합니다. 즉 : (풀 요청 번호가 123이라고 가정)
원격 추적 분기 '사용자 / 자신의 분기'를 분기에 병합
refs # 123 무엇이든 해결 ...
따라서 다음에 github issues / pull-requests 페이지를 방문하여 특정 pull 요청을 확인하면 병합을 수행 한 위치를 커밋 할 수있는 링크가있는 메시지가 표시됩니다.
여기 제가 의미하는 바의 스크린 샷이 있습니다.
그렇게하려면 저장소의 홈 페이지로 이동하여 브랜치를 클릭하고 기본 브랜치를 master에서 다른 것으로 변경합니다 (제 경우에는 "dev").
그 후 누군가가 풀 리퀘스트를 생성 할 때마다 merge버튼은 요청을 마스터가 아닌 "dev"로 자동 병합합니다.
