이미 원격 브랜치로 푸시된 병합 커밋을 되돌리는 방법은 무엇입니까?

질문자 :Yaz

git revert <commit_hash> 만으로는 작동하지 않습니다. -m 을 지정해야 하며 이에 대해 상당히 혼란스럽습니다.

누구든지 전에 이것을 경험 했습니까?

-m 옵션은 상위 번호를 지정합니다. 이는 병합 커밋에 둘 이상의 부모가 있고 Git이 자동으로 어떤 부모가 메인라인이고 어떤 부모가 병합 해제하려는 분기인지 알지 못하기 때문입니다.

git log 의 출력에서 병합 커밋을 볼 때 Merge 시작하는 줄에 나열된 부모를 볼 수 있습니다.

 commit 8f937c683929b08379097828c8a04350b9b8e183 Merge: 8989ee0 7c6b236 Author: Ben James <ben@example.com> Date: Wed Aug 17 22:49:41 2011 +0100 Merge branch 'gh-pages' Conflicts: README

이 상황에서, git revert 8f937c6 -m 1 가 있다는 당신에게 나무를 얻을 것이다 8989ee0 하고, git revert -m 2 가 있다는 트리를 복원합니다 7c6b236 .

상위 ID를 더 잘 이해하기 위해 다음을 실행할 수 있습니다.

 git log 8989ee0

그리고

 git log 7c6b236

Ben James

다음은 누군가에게 도움이 되기를 바라는 완전한 예입니다.

 git revert -m 1 <commit-hash> git push -u origin master

여기서 <commit-hash> 는 되돌리려는 병합의 커밋 해시이며 이 답변 -m 1 은 이전의 첫 번째 부모의 트리로 되돌리기를 원함을 나타냅니다. 병합.

git revert ... 라인은 기본적으로 변경 사항을 커밋하는 반면 두 번째 라인은 변경 사항을 원격 분기로 푸시하여 공개합니다.

Saheed

Ben은 병합 커밋을 되돌리는 방법을 알려 줬지만 그렇게 하는 것이 매우 중요 합니다.

"... 는 병합으로 인해 트리 변경 사항이 가져오는 것을 절대 원하지 않는다고 선언합니다. 결과적으로 나중에 병합하면 이전에 되돌린 병합의 조상이 아닌 커밋에 의해 도입된 트리 변경 사항만 가져올 것입니다. 이것은 될 수도 있고 아닐 수도 있습니다. 당신이 원하는 것. " (git-merge 매뉴얼 페이지) .

매뉴얼 페이지에서 링크된 기사/메일링 리스트 메시지 는 관련된 메커니즘과 고려 사항에 대해 자세히 설명합니다. 병합 커밋을 되돌리면 나중에 분기를 다시 병합하고 동일한 변경 사항이 다시 돌아올 것으로 기대할 수 없다는 것을 이해했는지 확인하십시오.

Ryan Stewart

다음 단계에 따라 잘못된 커밋을 되돌리거나 원격 분기를 올바른 HEAD/상태로 재설정할 수 있습니다.

1. 원격 지점을 로컬 저장소로 체크아웃하십시오.
   git checkout your_branch_name
2. git log -n5 에서 커밋 해시(즉, 잘못된 커밋 직전 커밋의 ID)를 복사합니다.

다음과 같이 보여야 합니다.

commit 7cd42475d6f95f5896b6f02e902efab0b70e8038 "'잘못된 커밋' 브랜치를 'your_branch_name'으로 병합"
커밋 f9a734f8f44b0b37ccea769b9a2fd774c0f0c012 "잘못된 커밋입니다" 커밋 3779ab50e72908da92d2cfcd72256d7a09f446ba "올바른 커밋입니다"

3. 분기를 이전 단계에서 복사한 커밋 해시로 재설정
   git reset <commit-hash> (ie 3779ab50e72908da92d2cfcd72256d7a09f446ba)
4. git status 를 실행하여 잘못된 커밋의 일부인 모든 변경 사항을 표시합니다.
5. 모든 변경 사항을 되돌리려면 git reset --hard 를 실행하기만 하면 됩니다.
6. 로컬 브랜치를 원격으로 강제 푸시하고 커밋 기록이 오염되기 전과 같이 깨끗한지 확인합니다.
   git push -f origin your_branch_name

참고: 이 솔루션은 공유 분기가 아닌 자신의 분기에만 적용하십시오.

ssasi

git revert -m 1 <merge-commit>

Neeraj Kumar

아무 일도 일어나지 않은 것처럼 로그를 깨끗하게 유지하려면(이 접근 방식의 몇 가지 단점이 있습니다(push -f로 인해)):

 git checkout <branch> git reset --hard <commit-hash-before-merge> git push -f origin HEAD:<remote-branch>

'commit-hash-before-merge'는 병합 후 로그(git log)에서 가져옵니다.

nvd

때때로 롤백에 대한 가장 효과적인 방법은 뒤로 물러서서 교체하는 것입니다.

git log

두 번째 커밋 해시(실수가 나열되기 전에 되돌리려는 전체 해시)를 사용한 다음 거기에서 다시 분기합니다.

git checkout -b newbranch <HASH>

그런 다음 이전 분기를 삭제하고 새 분기를 그 자리에 복사한 다음 거기에서 다시 시작합니다.

 git branch -D oldbranch git checkout -b oldbranch newbranch

브로드캐스트된 경우 모든 리포지토리에서 이전 분기를 삭제하고 다시 실행한 분기를 가장 중앙으로 푸시한 다음 다시 모두로 끌어내립니다.

ppostma1

모든 답변은 이미 대부분의 내용을 다루었지만 5센트를 추가하겠습니다. 간단히 말해서 병합 커밋을 되돌리는 것은 매우 간단합니다.

 git revert -m 1 <commit-hash>

권한이 있는 경우 "마스터" 브랜치로 직접 푸시할 수 있습니다. 그렇지 않으면 간단히 "되돌리기" 브랜치로 푸시하고 풀 리퀘스트를 생성하십시오.

https://itcodehub.blogspot.com/2019/06/how-to-revert-merge-in-git.html 에서 이 주제에 대한 더 유용한 정보를 찾을 수 있습니다.

xproph

merge 커밋을 되돌리려면 다음을 수행해야 합니다.

1. 먼저 git log 를 확인하여 병합 커밋의 ID를 찾습니다. 또한 병합과 관련된 여러 상위 ID를 찾을 수 있습니다(아래 이미지 참조).

노란색으로 표시된 병합 커밋 ID를 기록해 둡니다. 부모 ID는 다음 줄에 Merge: parent1 parent2 로 작성된 것입니다. 지금...

단편:

2. 병합이 이루어진 분기로 전환합니다. 그런 다음 git revert <merge commit id> -m 1 을 수행하면 커밋 메시지를 입력하기 위한 vi 쓰기, 저장, 종료, 완료!

긴 이야기:

2. 병합이 이루어진 분기로 전환합니다. 제 경우에는 test 브랜치이고 여기에서 feature/analytics-v3 브랜치를 제거하려고 합니다.

3. git revert 는 모든 커밋을 되돌리는 명령입니다. merge 커밋을 되돌릴 때 불쾌한 트릭이 있습니다. -m 플래그를 입력해야 합니다. 그렇지 않으면 실패합니다. 여기에서 다음을 통해 분기를 되돌리고 정확히 parent1 또는 parent2 에 있었던 것처럼 보이게 할지 여부를 결정해야 합니다.

git revert <merge commit id> -m 1 ( parent2 로 되돌리기)

git revert <merge commit id> -m 2 ( parent1 로 되돌리기)

이 부모를 git log하여 원하는 방향을 파악할 수 있으며 이것이 모든 혼란의 근원입니다.

saran3h

이 링크 에서 병합을 되돌리는 방법에 대한 좋은 설명을 찾았고 아래 설명을 복사하여 붙여넣었으며 아래 링크가 작동하지 않는 경우에 도움이 될 것입니다.

잘못된 병합을 되돌리는 방법 Alan(alan@clueserver.org)은 다음과 같이 말했습니다.

마스터 브랜치가 있습니다. 일부 개발자가 작업 중인 분기가 있습니다. 그들은 그것이 준비되어 있다고 주장합니다. 우리는 그것을 마스터 브랜치에 병합합니다. 그것은 무언가를 깨뜨리므로 병합을 되돌립니다. 그들은 코드를 변경합니다. 그들은 괜찮다고 말하고 우리는 다시 병합하는 지점에 도달합니다. 검사할 때 되돌리기 전에 수행된 코드 변경 사항은 마스터 브랜치에 없지만 이후의 코드 변경 사항은 마스터 브랜치에 있음을 알 수 있습니다. 그리고 이 상황에서 회복하는 데 도움을 요청했습니다.

"병합 되돌리기" 직후의 기록은 다음과 같습니다.

 ---o---o---o---M---x---x---W / ---A---B

여기서 A와 B는 그다지 좋지 않은 측면 개발에 있고, M은 이러한 조기 변경을 메인 라인으로 가져오는 병합, x는 사이드 분기가 메인 라인에서 수행하고 이미 수행한 것과 관련이 없는 변경이며 W는 " 병합 M의 되돌리기"(W가 M을 거꾸로 보지 않습니까?). IOW, "diff W^..W"는 "diff -RM^..M"과 유사합니다.

병합의 이러한 "되돌리기"는 다음을 사용하여 수행할 수 있습니다.

$ git revert -m 1 M 사이드 브랜치의 개발자가 실수를 수정한 후 기록은 다음과 같습니다.

 ---o---o---o---M---x---x---W---x / ---A---B-------------------C---D

여기서 C와 D는 A와 B에서 깨진 부분을 수정하기 위한 것이며 W 이후 메인라인에 이미 다른 변경 사항이 있을 수 있습니다.

업데이트된 측면 분기(끝에 D가 있음)를 병합하면 A 또는 B에서 수행된 변경 사항이 W에 의해 되돌려졌기 때문에 결과에 없습니다. 이것이 Alan이 본 것입니다.

Linus는 상황을 다음과 같이 설명합니다.

일반 커밋을 되돌리면 해당 커밋이 수행한 작업을 효과적으로 취소할 수 있으며 매우 간단합니다. 그러나 병합 커밋을 되돌리면 커밋이 변경된 데이터 도 실행 취소되지만 병합이 히스토리에 미치는 영향에는 전혀 영향을 미치지 않습니다. 따라서 병합은 여전히 존재하며 두 분기를 함께 결합하는 것으로 표시되며 향후 병합에서는 해당 병합을 마지막 공유 상태로 볼 수 있으며 가져온 병합을 되돌린 되돌리기는 전혀 영향을 미치지 않습니다. 는 "되돌리기"는 데이터 변경 사항을 실행 취소,하지만 매우 그것은의 효과가 저장소의 역사에 커밋 취소하지 않음을 의미하는 "실행 취소"아니에요 그래서. 따라서 "되돌리기"를 "실행 취소"로 생각하면 항상 되돌리기의 이 부분을 놓치게 됩니다. 예, 데이터를 취소하지만 아니요, 기록을 취소하지 않습니다. 이러한 상황에서는 먼저 이전 되돌리기를 원할 것입니다. 이렇게 하면 기록이 다음과 같이 표시됩니다.

 ---o---o---o---M---x---x---W---x---Y / ---A---B-------------------C---D

여기서 Y는 W의 되돌리기입니다. 이러한 "되돌리기"는 다음과 같이 수행할 수 있습니다.

$ git revert W 이 기록은 (W와 W..Y가 변경된 것 사이의 가능한 충돌을 무시함) 기록에 W 또는 Y가 전혀 없는 것과 같습니다.

 ---o---o---o---M---x---x-------x---- / ---A---B-------------------C---D

사이드 브랜치를 다시 병합하면 이전 되돌리기 및 되돌리기의 되돌리기에서 발생하는 충돌이 발생하지 않습니다.

 ---o---o---o---M---x---x-------x-------* / / ---A---B-------------------C---D

물론 C와 D의 변경 사항은 여전히 x 중 하나가 수행한 작업과 충돌할 수 있지만 이는 일반적인 병합 충돌일 뿐입니다.

MK446

이것은 매우 오래된 스레드이지만 내 의견으로는 편리한 솔루션이 하나 빠져 있습니다.

나는 병합을 되돌리지 않습니다. 모든 것이 정상이었던 개정판에서 다른 분기를 만든 다음 그 사이에 추가된 이전 분기에서 선택해야 하는 모든 것을 체리 선택합니다.

따라서 GIT 기록이 다음과 같은 경우:

• NS
• 씨
• b <<< 병합
• NS
• ...

나는 체리 픽 c와 d에서 새 가지를 만들고 b에서 새 가지를 지웁니다. 내 새 지점에서 "b"를 다시 병합하기로 결정할 수 있습니다. 이전 분기는 더 이상 사용되지 않으며 "b"가 더 이상 필요하지 않거나 여전히 다른(기능/핫픽스) 분기에 있으면 삭제됩니다.

유일한 문제는 이제 컴퓨터 과학에서 가장 어려운 것 중 하나입니다. 새 지점의 이름을 어떻게 지정합니까? ;)

좋아, 당신이 실패했다면 esp. devel에서 위에서 언급한 대로 newdevel을 만들고 이전 devel을 삭제하고 newdevel의 이름을 devel로 바꿉니다. 임무 완수. 이제 원할 때 변경 사항을 다시 병합할 수 있습니다. 한 번도 병합되지 않은 것처럼....

miwoe

알고 있는 두 끝점 사이에 역 패치를 만들고 해당 패치를 적용하면 효과가 있다는 것을 알았습니다. 이것은 마스터 브랜치에서 스냅샷(태그)을 생성했거나 마스터 브랜치의 백업이 master_bk_01012017이라고 가정한다고 가정합니다.

마스터에 병합한 코드 분기가 mycodebranch라고 가정합니다.

1. 체크아웃 마스터.
2. 마스터와 백업 간에 전체 바이너리 역 패치를 생성합니다. git diff --binary master..master_bk_01012017 > ~/myrevert.patch
3. 패치 확인 git apply --check myrevert.patch
4. 사인오프로 패치 적용 git am --signoff < myrevert.patch
5. 이 코드가 수정되면 다시 가져와야 하는 경우 되돌린 마스터를 분기하고 수정 분기 git branch mycodebranch_fix git checkout mycodebranch_fix
6. 여기에서 되돌리기를 위한 SHA 키를 찾고 되돌리기 git revert [SHA]
7. 이제 mycodebranch_fix를 사용하여 문제를 수정하고 완료되면 마스터에 커밋하고 다시 병합할 수 있습니다.

alexplain

올바르게 표시된 답변은 저에게 효과가 있었지만 무슨 일이 일어나고 있는지 확인하는 데 시간이 걸렸습니다. 그래서 저와 같은 경우에 간단한 간단한 단계로 답변을 추가하기로 결정했습니다.

브랜치 A와 B가 있다고 가정해 봅시다. 브랜치 A를 브랜치 B로 병합하고 브랜치 B를 자체로 푸시하여 이제 병합이 일부입니다. 그러나 병합 전 마지막 커밋으로 돌아가고 싶습니다. 당신은합니까?

1. git 루트 폴더(일반적으로 프로젝트 폴더)로 이동하여 git log

2. 최근 커밋의 기록을 볼 수 있습니다. 커밋에는 commit/author/date 속성이 있고 병합에도 merge 속성이 있으므로 다음과 같이 표시됩니다.

   commit: <commitHash> Merge: <parentHashA> <parentHashB> Author: <author> Date: <date>

3. git log <parentHashA> 및 git log <parentHashB> - 해당 상위 분기의 커밋 기록이 표시됩니다. 목록의 첫 번째 커밋이 최신 커밋입니다.

4. 원하는 커밋의 <commitHash> 를 가져오고 git 루트 폴더로 이동한 다음 git git checkout -b <newBranchName> <commitHash> 를 사용합니다. 그러면 병합 전에 선택한 마지막 커밋에서 시작하는 새 분기가 생성됩니다. 짜잔, 준비됐어!

Божидар Йовчев

git revert -m에 대한 git doc은 이를 정확히 설명하는 링크를 제공합니다. https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt

Junyong

-m1은 수정 중인 현재 분기의 마지막 부모이고, -m 2는 여기에 병합된 분기의 원래 부모입니다.

명령줄이 혼란스러운 경우 Tortoise Git도 도움이 될 수 있습니다.

Vinay

방금 푸시한 변경 사항을 되돌리려는 경우 매우 간단한 대답:

 commit 446sjb1uznnmaownlaybiosqwbs278q87 Merge: 123jshc 90asaf git revert -m 2 446sjb1uznnmaownlaybiosqwbs278q87 //does the work

arqam

또한 GitHub 리포지토리의 마스터 브랜치에 병합된 PR에서 이 문제에 직면했습니다.

일부 수정된 파일만 수정하고 싶었지만 PR이 가져온 전체 변경 사항은 수정하지 않았기 때문에 merge commit 을 git commit --am amend 해야 했습니다.

단계:

1. 일부 수정된 파일을 변경/되돌리려는 분기로 이동
2. 수정된 파일에 따라 원하는 대로 변경
3. git add * 또는 git add <file>
4. git commit --am 실행하고 유효성을 검사하십시오.
5. git push -f 실행

흥미로운 이유:

• PR 작성자 커밋을 변경하지 않은 상태로 유지합니다.
• git tree를 망가뜨리지 않는다.
• 커미터로 표시됩니다(커밋 작성자 병합은 변경되지 않음).
• Git은 충돌을 해결한 것처럼 작동하고 GitHub에 있는 그대로 병합하지 않도록 수동으로 지시하는 것처럼 수정된 파일의 코드를 제거/변경합니다.

Maxime Lafarie

git log 의 출력에서 병합 커밋을 볼 때 Merge 시작하는 줄에 나열된 부모를 볼 수 있습니다.

 commit 8f937c683929b08379097828c8a04350b9b8e183 Merge: 8989ee0 7c6b236 Author: Ben James <ben@example.com> Date: Wed Aug 17 22:49:41 2011 +0100 Merge branch 'gh-pages' Conflicts: README

이 상황에서, git revert 8f937c6 -m 1 가 있다는 당신에게 나무를 얻을 것이다 8989ee0 하고, git revert -m 2 가 있다는 트리를 복원합니다 7c6b236 .

상위 ID를 더 잘 이해하기 위해 다음을 실행할 수 있습니다.

 git log 8989ee0

그리고

 git log 7c6b236

백업 분기 가져오기

 git checkout -b mybackup-brach git reset --hard 8989ee0 git push origin -u mybackup-branch

이제 병합하기 전에 변경 사항이 있습니다. 모든 것이 정상이면 이전 분기로 체크 아웃하고 백업 분기로 재설정하십시오.

 git reset --hard origin/mybakcup-branhc

AnilS

저에게는 분기된 마스터 브랜치에서 오리진 마스터로 리포지토리에 대한 PR이 있었습니다. 업스트림을 가져올 때 병합 커밋이 추가되었습니다. 내 브랜치가 1 커밋 앞서고 몇 100 커밋 뒤에 있었기 때문입니다. 따라서 자동으로 병합 커밋을 추가합니다.

따라서 이를 제거하려면 다음 명령을 실행해야 했습니다.

 git reset --hard HEAD~1 git push -f origin

그것은 그 병합을 제거했습니다. 그리고 모든 것이 정상으로 돌아왔습니다.

foragerDev

Ryan이 언급했듯이 git revert 는 병합을 어렵게 만들 수 있으므로 git revert 가 원하는 것이 아닐 수 있습니다. git reset --hard <commit-hash-prior-to-merge> 명령을 사용하는 것이 더 유용하다는 것을 알았습니다.

하드 리셋 부분을 완료 한 후에는 다음 원격 지점, 즉,에 밀어 강제 git push -f <remote-name> <remote-branch-name> , <remote-name> 자주 이름이 origin . 그 시점부터 원하는 경우 다시 병합할 수 있습니다.

Harry Wang

출처 : http:www.stackoverflow.com/questions/7099833/how-to-revert-a-merge-commit-thats-already-pushed-to-remote-branch