풀 요청으로 병합을 취소 하시겠습니까?


159

누군가가 가져서는 안되는 풀 요청을 수락했습니다. 이제 깨진 코드가 많이 병합되었습니다. 풀 요청을 어떻게 취소합니까? 병합 직전에 커밋의 변경 사항을 되돌리려 고했지만 커밋이 많이 병합 된 것을 알았습니다. 이제 병합하기 며칠 전부터이 사람의 커밋이 모두 이루어졌습니다. 이 작업을 어떻게 취소합니까?


7
수락 된 답변에 대한 조언에도 불구하고, 리포지토리가 다른 사람과 공유되는 경우 PLEASE는 저장소로 강제 푸시하지 않습니다. 다른 사람이 저지른 작업을 망칠 위험이 있으며 GitHub는 해당 풀 요청이 병합 된 것으로 계속 표시 할 수 있습니다. 이 질문에 대한 또 다른 대답은 풀 요청을 실행 취소하는보다 안전한 방법을 설명합니다.
alxndr

2
참고 : 적어도 지금 (2014 년 6 월) GitHub는 Pull Request 웹 GUI에 "Revert"버튼을 제안합니다. 아래 내 답변
VonC 2016 년

1
되돌리기 버튼의 문제는 풀 요청에 반비례하여 새로운 커밋을 생성한다는 것입니다. 즉, 이러한 변경 사항을 결국 병합하려면 "되돌리기"버튼을 사용하면 훨씬 더 어려워 질 수 있습니다.
FluffySamurai

답변:


159

이 문제를 단계별로 세분화 할 수는 있지만이 문제에 대한 더 나은 대답 이 있습니다.

다음과 같이 최신 업스트림 변경 사항을 가져오고 체크 아웃해야합니다. 예 :

git fetch upstream
git checkout upstream/master -b revert/john/foo_and_bar

커밋 로그를 살펴보면 다음과 비슷한 것을 찾을 수 있습니다.

commit b76a5f1f5d3b323679e466a1a1d5f93c8828b269
Merge: 9271e6e a507888
Author: Tim Tom <tim@tom.com>
Date:   Mon Apr 29 06:12:38 2013 -0700

    Merge pull request #123 from john/foo_and_bar

    Add foo and bar

commit a507888e9fcc9e08b658c0b25414d1aeb1eef45e
Author: John Doe <john@doe.com>
Date:   Mon Apr 29 12:13:29 2013 +0000

    Add bar

commit 470ee0f407198057d5cb1d6427bb8371eab6157e
Author: John Doe <john@doe.com>
Date:   Mon Apr 29 10:29:10 2013 +0000

    Add foo

이제 나중에 되돌릴 수있는 기능으로 전체 풀 요청을 되돌리려 고합니다. 그렇게하려면 merge commit 의 ID를 가져와야 합니다.

위의 예에서 병합 커밋"Merged pull request # 123 ..." 이라는 최상위 커밋 입니다 .

이렇게하면 두 변경 사항 ( "Add bar""Add foo" )을 모두 되돌릴 수 있으며, 나중에 되돌릴 수없고 변경 히스토리를 깨끗하게 유지할 수있는 전체 풀 요청을 되돌릴 수 있습니다.

git revert -m 1 b76a5f1f5d3b323679e466a1a1d5f93c8828b269

6
이것이 정답이어야합니다. 여기에 자식 메일 링리스트에서 더 많은 세부 사항에 자식-되돌리기 man 페이지에서 참조가 kernel.org/pub/software/scm/git/docs/howto/...~~V은
저스틴 Hamade

2
git checkout upstream/master -b revert/john/foo_and_bar? 정확히 무엇을합니까?
Magne

4
@Magne-되돌리기를 수행 할 새 브랜치를 생성 한 후 복귀를 병합 할 위치를 선택할 수 있습니다. 기본적으로 브랜치로 무엇을해야하는지 더 잘 제어 할 수 있습니다. 필자의 경우,이 "고정 된"브랜치에서 개발 브랜치로의 복귀가 포함 된 새 풀 요청을 제출했습니다. 즉, 필요한 경우 새 풀 요청도 되돌릴 수 있습니다. 이것은 우리가 예정을 변경 한 기능의 첫 번째 초안을 꺼내기로 결정한 릴리스에서 수행되었습니다. 이 릴리스에서는 잘못된 코드가 없습니다.
Daniel Nalbach

3
나는 이것에 대한 어려운 교훈을 배웠다. 우리는 기능을 개발 브랜치에 푸시했지만 데이터 문제가 있음을 깨달았고 개발시 직접 되돌 렸습니다. 나중에 문제가 해결되었을 때 푸시하기 전에이 기능과의 호환성을 테스트하기 위해 최신 개발 기능을이 분기에 다시 추가하고 싶었습니다. 따라서 개발 기능을 기능 분기로 다시 병합했습니다. 또한 기능 브랜치에 대한 모든 변경 사항을 기록하지 않은 복귀 커밋을 적용했습니다. > <
Greg

86

커밋 그래프를 확인하십시오 (gitk 또는 유사한 프로그램 사용). 풀 요청에서 커밋을 볼 수 있으며 자신의 커밋과 병합 커밋 (앞으로 빨리 병합되지 않은 경우)이 표시됩니다. 병합하기 전에 마지막 커밋을 찾아 분기를이 커밋으로 다시 설정하면됩니다.

분기의 참조 로그가 있으면 병합 전에 커밋을 찾는 것이 훨씬 쉬워집니다.


(의견에서 더 많은 정보를 얻은 후 편집 :)

좋아, 그래프를 보자.

스크린 샷 1

마지막 (가장 오른쪽) 커밋은 pull request에 의한 잘못된 병합 이라고 가정 했는데 여기에 표시된 파란색 선이 병합되었습니다. 마지막으로 성공한 커밋은 검은 색 선의 앞에있는 것입니다.

여기에 이미지 설명을 입력하십시오

이 커밋으로 재설정하면 괜찮을 것입니다.

즉, 로컬 작업 복사본 에서이 작업을 수행하십시오 (예 : git stash와 같은 커밋되지 않은 항목이 없는지 확인한 후).

git checkout master
git reset --hard 7a62674ba3df0853c63539175197a16122a739ef
gitk 

이제 내가 표시 한 커밋에 실제로 있는지 확인하면 조상에서 가져온 항목이 표시되지 않습니다.

git push -f origin master

(github remote origin의 이름 이 지정된 경우 -그렇지 않으면 이름을 변경하십시오).

이제 모든 것이 github에서도 올바르게 보입니다. 커밋은 여전히 ​​저장소에 있지만 지점에서 도달 할 수 없으므로 해를 끼치 지 않아야합니다. (물론 그들은 여전히 ​​RogerPaladin의 저장소에있을 것입니다.)

(Github 고유의 웹 전용 방식으로 동일한 작업을 수행 할 수 있지만 Github 및 풀 요청 관리 시스템에 익숙하지 않습니다.)

참고 다른 사람이 이미 잘못 사용하여 마스터가 커밋 뽑아 수도 경우, 그들은 당신이 현재 가지고있는 다음 같은 문제가, 정말 다시 기여할 수 없다. 새 마스터 버전으로 재설정하기 전에

이런 일이 발생했거나 단순히 문제를 피하려면, git revert대신 명령을 사용 git reset하여 이전 커밋으로 다시 설정하지 않고 새 커밋으로 변경 사항을 되 돌리십시오. (일부 사람들은 게시 된 지점으로 재설정하지 않아야한다고 생각합니다.)이 방법에 대한이 질문에 대한 다른 답변을 참조하십시오.

미래를 위해 :

RogerPaladin 지점의 커밋 중 일부만 원한다면 cherry-pick대신 대신 사용하십시오 merge. 또는 RogerPaladin과 통신하여 별도의 지점으로 이동하여 새 당김 요청을 보내십시오.


그러나 우리는 병합과 그의 첫 커밋 사이에 많은 커밋이 있습니다. 따라서 병합 커밋, 자체 커밋 및 다른 커밋이 있습니다. 그의 오래된 커밋에 합병 된 것 같습니다.

예, 병합 된 커밋의 조상 인 (그리고 이미 커밋의 조상이 아닌) 모든 것에 병합됩니다. 이것은 재설정을 방해하지 않아야합니다-나중에 rebase하지 않으면 커밋이 스스로 순서를 바꾸지 않습니다.
Paŭlo Ebermann 2018

1
네, 이제는 옳아 보입니다 (이상한 병합 과는 별도로 -네트워크 그래프 소프트웨어에 결함이있을 수 있습니다). :-) 도와 드리겠습니다.
Paŭlo Ebermann 2016

6
누군가가 나쁜 커밋을 가져 와서 나중에 같은 나쁜 커밋이 포함 된 끌어 오기 요청을 보내면 문제가 될 수 있다고 생각합니다. 잘못된 커밋을 취소하는 새로운 커밋을 만드는 것이 더 안전하지 않습니까? 그렇게하면 잘못된 커밋이 다른 지점 / 포크로 당겨지면 다른 분기 / 포크로 다른 끌어 오기에 의해 효과적으로 제거됩니까? 나는 이것을 사실로 말하지 않고, 이것이 OP와 같은 입장에 있고 내 옵션을 고려하는 데 한 시간 정도를 보냈다는 것이 사실 이라고 생각 합니다.
Myles McDonnell

4
@이 대답을 받아들이지 않는 것이 좋습니다. 이것은 아직 추진되지 않은 코드 괜찮 (이 경우, 더 관련 SO 질문이지만, 코드 (이 경우 역사를 다시 쓰는 자식 명령을하고, 공개적으로 공유되는, reset --hard그리고 힘 푸시입니다 아래 @errordeveloper의 답변은 역사를 다시 쓰거나 강요하지 않고이를 수행하는 방법을 보여줍니다.
asmeurer

34

풀이 그가 한 마지막 일이라면

git reset --hard HEAD~1

3
이 지시에 따라 조심하십시오. 실제로 한 단계가 아닌 2 단계를 되돌려 놓았습니다.
szeitlin

1
@szeitlin 어떻게 한 단계가 아닌 2 단계를 다시 거쳤습니까? 나는이 의견이 4 년 이상 전에 남았다는 것을 알고 있지만 누군가 어떻게 대답 할 수 있는지 궁금합니다. 이것은 나에게 매우 중요합니다. 감사.
Haradzieniec 2016 년

지금은 기억 나지 않지만 재설정하려고 할 때 새로운 커밋을 한 경우 발생할 수 있다고 생각합니까? 걱정된다면 더미 레포로 테스트 해보십시오.
szeitlin

이것은 나를 위해 잘 작동했습니다. 최근 병합 된 풀 요청을 삭제했습니다. 후에 는 원격 저장소를 업데이트하는 git reset --hard HEAD~1데 사용 git push origin -f했습니다. 그러나이 작업을 수행하기 전에주의하십시오.
Denis Oluka

24

2014 년 6 월 24 일부터 다음을 사용하여 PR을 쉽게 취소 할 수 있습니다 ( " 풀 요청 되돌리기 "참조 ).

되돌리기 버튼 소개

되돌리기를 클릭하면 GitHub에서 풀 요청을 쉽게 되돌릴 수 있습니다.

https://camo.githubusercontent.com/0d3350caf2bb1cba53123ffeafc00ca702b1b164/68747470733a2f2f6769746875622d696d616765732e73332e616d617a6f6e6177732e636f6d2f68656c702f70756c6c5c72d6fcccccccccccccccfc65c72f72576765747476574747657474765747476574747657474765747476574747657474765765747476576574747657657474765765747476574747657474765765477265765747476576547725765765747655772657657476557796576574765577965765747655779657657476557796576574765577965765747655779

되 돌린 변경 사항으로 새 풀 요청을 작성하라는 메시지가 표시됩니다.

https://camo.githubusercontent.com/973efae3cc2764fc1353885a6a45b9a518d9b78b/68747470733a2f2f6769746875622d696d616765732e73332e616d617a6f6e6177732e636f6d2f68656c702f70756c6c5d72d65765737657656572656573765737576576573765737656573757657657376573757657653772656573765765577965765

그 되돌리기가 사용되는지 아닌지에 대한 테스트는 남아 있습니다 -m(병합을 되돌리기 위해)

그러나 Adil H Raza 는 다음과 같이 의견을 추가합니다 (2019 년 12 월).

이것이 예상되는 동작이며 새 분기를 만들었으며이 새 분기에서에 대한 PR을 만들 수 있습니다 master.
이렇게하면 나중에 필요한 경우 되돌리기를 되돌릴 수 있습니다 master. 가장 안전한 옵션이며 직접을 변경하지 않아도됩니다 .


경고 : Korayem는 지적 코멘트에 그 :

복귀 후 Git 지점에서 추가 변경을 수행하고 동일한 소스 / 대상 지점에서 새 PR을 작성했다고 가정 해 봅시다.
PR에는 새로운 변경 사항 만 표시되지만 되돌리기 전에는 아무것도 없었습니다 .

Korayem은 " Github : 되돌리기 후 변경 사항 무시 ( git cherry-pick, git rebase) "를 참조합니다.


나는 이것을 시도하고 마스터에서 PR을 취소하는 대신 새 분기를 만들었습니까?
Грозный

이상한. 그 행동을 설명하기 위해 새로운 질문을 할 수 있습니까?
VonC

예상되는 동작이며 새 분기를 만들었으며이 새 분기에서 마스터로 PR을 만들 수 있습니다. 이 방법으로 나중에 필요한 경우 되돌리기를 되돌릴 수 있습니다. 가장 안전한 옵션이며 마스터를 직접 변경하지 않습니다.
Adil H. Raza

1
@ AdilH.Raza 감사합니다. 더 많은 가시성을 제공하기 위해 귀하의 의견을 답변에 포함 시켰습니다.
VonC

1
@VonC의 손가락을 넘어 서면 전세계 개발자들이 너무 많은 고통과 시간 낭비로부터
구해줄 것입니다

8

삭제하고 싶지 않은 커밋으로 github pull 요청을 취소하려면 다음을 실행해야합니다.

git reset --hard --merge <commit hash>

풀 요청을 병합하기 전에 커밋 해시가 커밋 우선입니다. 그러면 히스토리 내에서 커밋에 영향을주지 않고 풀 요청에서 모든 커밋이 제거됩니다.

이것을 찾는 좋은 방법은 지금 닫힌 끌어 오기 요청으로 이동하여이 필드를 찾는 것입니다.

풀 요청 이미지 풀 요청 이미지

을 실행 한 후 다음을 실행하십시오 git reset.

git push origin --force <branch name>

이것은 풀 요청으로부터의 커밋 사이의 커밋 히스토리에 영향을 미치는 분기의 커밋에 영향을 미치지 않고 풀 요청 전에 브랜치를 되돌려 야합니다.

편집하다:

풀 요청에서 되돌리기 버튼을 클릭하면 분기에 추가 커밋이 생성됩니다. 커밋 해제 또는 병합 해제하지 않습니다. 즉, 되돌리기 버튼을 누르면이 풀 코드를 모두 다시 추가하기 위해 새 풀 요청을 열 수 없습니다.


미친 되돌리기 나 체리 따기를 필요로하지 않고 일을 바로 잡을 수있는 좋은 방법
Cumulo Nimbus

감사! 그것은 내가 계획하고 있었던 것이었지만, 체리 픽업에 약 200 번의 커밋이 있었을 것입니다.
FluffySamurai

1

나는 항상이 장소를 사용합니다. 감사합니다.

풀 요청을 취소하는 방법을 찾고 있었고 여기에 도착했습니다.

나는 git reset --hard"오래 전에"하려고했고, 풀 요청을하기 전에 내가있는 곳으로 빨리 돌아갔다.

여기를 보지 않고 동료에게 무엇을했는지 물었고 위의 첫 번째 답변에서 예제 출력을 사용하여 좋은 대답을 얻었습니다.

git reset --hard 9271e6e

Git의 대부분의 작업과 마찬가지로 쉽지 않은 방식으로 수행한다면 아마도 잘못했을 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.