pull 중 변경 사항을 위해 Git 병합 충돌 해결

질문자 :sanmai

끌어온 변경 사항을 위해 자식 병합 충돌을 어떻게 해결합니까?

기본적으로 충돌 없는 모든 변경 사항을 유지하면서 git mergetool 을 사용하여 모든 충돌을 거치지 않고도 작업 트리에서 충돌하는 모든 변경 사항을 제거해야 합니다. 이후가 아니라 당기는 동안 이 작업을 수행하는 것이 좋습니다.

git pull -s recursive -X theirs <remoterepo or other repo>

또는 간단히 기본 리포지토리의 경우:

 git pull -X theirs

이미 충돌 상태에 있는 경우...

 git checkout --theirs path/to/file

Pascal Fares

재귀 "그들"전략 옵션을 사용할 수 있습니다.

git merge --strategy-option theirs

남자 에게서 :

 ours This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it. theirs This is opposite of ours.

참고 : man 페이지 말한대로의 "우리"병합 전략 옵션은 "우리의"병합 전략에서 매우 다르다.

Ikke

이미 충돌 상태이고 모든 항목 을 수락하려는 경우:

 git checkout --theirs . git add .

반대로 하고 싶다면:

 git checkout --ours . git add .

이것은 매우 과감하므로 수행하기 전에 이와 같이 모든 것을 지우고 싶은지 확인하십시오.

lots-to-learn

자, 내가 있었던 시나리오를 상상해 보세요.

merge 시도하거나 cherry-pick 시도하면 중지됩니다.

 $ git cherry-pick 1023e24 error: could not apply 1023e24... [Commit Message] hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit'

이제 충돌 파일을 보고 변경 사항을 유지하고 싶지 않습니다. 위의 경우 IDE가 자동으로 추가한 줄 바꿈에서 파일이 충돌했습니다. 변경 사항을 취소하고 변경 사항을 수락하는 가장 쉬운 방법은 다음과 같습니다.

 git checkout --theirs path/to/the/conflicted_file.php git add path/to/the/conflicted_file.php

이것의 반대(수신 버전을 귀하의 버전으로 덮어쓰기)는 다음과 같습니다.

 git checkout --ours path/to/the/conflicted_file.php git add path/to/the/conflicted_file.php

놀랍게도 인터넷에서 이 답변을 쉽게 찾을 수 없었습니다.

Theodore R. Smith

git merge 후 충돌이 발생하여

 git checkout --theirs . git checkout --ours .

Mohit Kanojia

git pull -X theirs 답변은 추악한 병합 커밋을 생성하거나 문제를 일으킬 수 있습니다.

오류: 다음 파일에 대한 로컬 변경 사항은 병합에 의해 덮어쓰여집니다.

예를 들어 항상 원본의 미러여야 하는 클라이언트에서와 같이 리포지토리에서 파일에 대한 로컬 수정 사항을 무시하려면 다음을 실행합니다( master 를 원하는 분기로 교체).

 git fetch && git reset --hard origin/master

어떻게 작동합니까? git fetch git pull 하지만 병합하지 않습니다 . 그런 다음 git reset --hard 작업 트리를 마지막 커밋과 일치시킵니다. 리포지토리에 있는 파일에 대한 모든 로컬 변경 사항은 삭제 되지만 새 로컬 파일은 그대로 남습니다.

Dan Dascalescu

특정 분기의 버전과의 모든 충돌을 해결하려면:

 git diff --name-only --diff-filter=U | xargs git checkout ${branchName}

따라서 이미 병합 상태에 있고 충돌하는 파일의 마스터 버전을 유지하려는 경우:

 git diff --name-only --diff-filter=U | xargs git checkout master

Ariel Alvarez

때때로 이것이 작동하지 않습니다 .

git checkout --우리의 경로/대상/파일

또는

git checkout --자신의 경로/대상/파일

HEAD가 우리 것이고 MERGE_HEAD가 그들의 것이라고 가정하고 대신 이것을 했습니다.

 git checkout HEAD -- path/to/file

또는:

 git checkout MERGE_HEAD -- path/to/file

우리가 이것을 한 후에 우리는 좋습니다:

 git add .

더 자세히 알고 싶다면 torek의 멋진 게시물을 참조하세요. git checkout --ours는 병합되지 않은 파일 목록에서 파일을 제거하지 않습니다.

Nicolas D

VS Code(통합 Git) IDE 사용자:

충돌 파일에서 들어오는 모든 변경 사항 을 수락하려면 다음 단계를 수행하십시오.

 1. Go to command palette - Ctrl + Shift + P 2. Select the option - Merge Conflict: Accept All Incoming

마찬가지로 모두 수락, 현재 모두 수락 등과 같은 다른 옵션에 대해 수행할 수 있습니다.

SridharKritha

이미 충돌 상태에 있고 경로를 하나씩 확인하고 싶지 않은 경우. 당신은 시도 할 수 있습니다

 git merge --abort git pull -X theirs

Lee Chee Kiam

develop 변경된 파일, 두 분기의 다른 위치에 추가된 파일 등을 삭제한 장기 실행 next-version

next-version 브랜치의 전체 내용을 모두 한 번의 병합 커밋 develop

나를 위해 일한 위의 명령 조합은 다음과 같습니다.

 git merge -X theirs next-version # lots of files left that were modified on develop but deleted on next-version git checkout next-version . # files removed, now add the deletions to the commit git add . # still have files that were added on develop; in my case they are all in web/ git rm -r web

새로운 답변이 아니라 부분적으로 이러한 모든 답변이 필요할 수 있음을 확인하기 위해 많은 답변의 비트를 결합하는 것입니다.

Gordon

git checkout --ours/theirs 는 충돌을 독점적으로 해결하지 않습니다. ours/theirs 파일에서 체크아웃(전체 파일을 가져옴)합니다.

두 개의 커밋/분기/트리/무엇이든 변경 사항이 있는 foo 파일이 있다고 가정합니다. 수정 사항과 함께 충돌이 발생하고 ours 를 사용하여 checkout --ours foo 를 사용하면 충돌을 일으키는 변경 사항은 물론 수정 사항도 무시됩니다.

SED 사용

다음을 사용하여 해결:

sed -i -e '/<<<<<<</,/=======/d' -e '/>>>>>>>/d' foo

• -i 파일을 제자리에서 수정합니다.
• /<<<<<<</,/=======/d <<<<<<< 및 ======= (우리)를 포함하여 그 사이의 모든 것을 삭제합니다.
• />>>>>>>/d 나머지 충돌 마커 삭제
• -e SED에 여러 패턴을 지정합니다.
• foo 파일

우리를 사용하여 해결:

sed -i -e '/<<<<<<</d' -e '/=======/,/>>>>>>>/d' foo

CervEd

https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging에서

이것은 기본적으로 가짜 병합을 수행합니다. 두 브랜치를 부모로 하는 새로운 병합 커밋을 기록하지만 병합 중인 브랜치를 보지도 않습니다. 단순히 현재 브랜치의 정확한 코드를 병합한 결과로 기록합니다.

 $ git merge -s ours mundo

'우리' 전략으로 이루어진 합병.

 $ git diff HEAD HEAD~

우리가 있던 브랜치와 병합 결과에 차이가 없음을 알 수 있습니다.

이것은 기본적으로 Git이 나중에 병합을 수행할 때 분기가 이미 병합되었다고 생각하도록 속이는 데 유용할 수 있습니다. 예를 들어, 릴리스 분기에서 분기하고 작업을 수행하여 어느 시점에서 마스터 분기로 다시 병합하려는 작업을 수행했다고 가정해 보겠습니다. 그 동안 마스터의 일부 버그 수정은 릴리스 분기로 백포트해야 합니다. bugfix 브랜치를 릴리스 브랜치에 병합하고 -s ours 같은 브랜치를 마스터 브랜치에 병합할 수 있으므로(수정 사항이 이미 있더라도) 나중에 릴리스 브랜치를 다시 병합할 때 bugfix에서 충돌이 없습니다.

마스터가 새 주제 분기의 변경 사항을 반영하도록 하려면 상황이 유용하다고 생각했습니다. 나는 -Xirs가 어떤 상황에서는 충돌 없이 병합되지 않는다는 것을 알아차렸습니다... 예를 들어

 $ git merge -Xtheirs topicFoo CONFLICT (modify/delete): js/search.js deleted in HEAD and modified in topicFoo. Version topicFoo of js/search.js left in tree.

이 경우 내가 찾은 해결책은

 $ git checkout topicFoo

topicFoo에서 -s ours 전략을 사용하여 master에서 먼저 병합하면 topicFoo의 상태인 가짜 커밋이 생성됩니다. $ git merge -s 우리의 마스터

생성된 병합 커밋 확인

 $ git log

이제 마스터 브랜치를 확인하십시오.

 $ git checkout master

topic 분기를 다시 병합하지만 이번에는 -Xtheirs 재귀 전략을 사용합니다. 그러면 topicFoo 상태의 마스터 분기가 표시됩니다.

 $ git merge -X theirs topicFoo

Amos Folarin

출처 : http:www.stackoverflow.com/questions/10697463/resolve-git-merge-conflicts-in-favor-of-their-changes-during-a-pull