당김 동안 변경 사항에 찬성하여 Git 병합 충돌 해결

변경 사항을 가져 오기 위해 git merge 충돌을 어떻게 해결합니까?

기본적으로 충돌없는 git mergetool모든 변경 사항을 유지하면서 잠시 동안 모든 충돌 을 거치지 않고 작업 트리에서 충돌하는 모든 변경 사항을 제거해야합니다 . 나중에 당기지 않고 당기는 것이 좋습니다.

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

또는 간단히 기본 저장소의 경우 :

git pull -X theirs

이미 충돌 상태 인 경우 ...

git checkout --theirs path/to/file

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

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 페이지 말한대로의 "우리"병합 전략 옵션 은 "우리의"병합 매우 다르다 전략 .

이미 충돌 상태에 있고 모든 것을 수락하려면 다음을 수행하십시오.

git checkout --theirs .
git add .

당신이 반대를하고 싶다면 :

git checkout --ours .
git add .

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

좋아, 내가 방금 있었던 시나리오를 상상해보십시오.

당신은 시도 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

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

그 git pull -X theirs대답은 못생긴 병합 커밋을 만들거나

오류 : 다음 파일에 대한 로컬 변경 사항을 병합하여 덮어 씁니다.

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

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

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

git merge 후 충돌이 발생하고 자신 또는 자신이 원하는 경우

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

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

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

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

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

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

git checkout-경로 / 파일 / 파일

또는

자식 체크 아웃-경로 / 파일 / 파일

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

git checkout HEAD -- path/to/file

또는:

git checkout MERGE_HEAD -- path/to/file

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

git add .

자세한 내용을 보려면 여기에서 멋진 torek 게시물을 참조하십시오 : git checkout-우리는 병합되지 않은 파일 목록에서 파일을 제거하지 않습니다

VS 코드 (통합 Git) IDE 사용자 :

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

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

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

에 next-version변경 된 develop파일, 두 지점의 다른 위치에 추가 된 파일 등 이 많이 삭제 된 장기 실행 브랜치 가있었습니다.

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

새로운 답변이 아니며 많은 답변의 비트를 결합하여 부분적으로 이러한 답변이 모두 필요할 수 있음을 보장합니다 .

이미 충돌 상태에 있고 경로를 하나씩 체크 아웃하지 않으려는 경우. 당신은 시도 할 수 있습니다

git merge --abort
git pull -X theirs

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

이것은 기본적으로 가짜 병합을 수행합니다. 두 분기를 모두 부모로하여 새 병합 커밋을 기록하지만 병합하려는 분기도 보지 못합니다. 병합 결과로 현재 분기의 정확한 코드를 기록합니다.

$ git merge -s ours mundo

'우리의'전략에 의해 합병.

$ git diff HEAD HEAD~

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

이것은 종종 나중에 병합을 할 때 브랜치가 이미 병합되었다고 생각하도록 Git을 속이는 데 유용 할 수 있습니다. 예를 들어 릴리스 지점을 분기하고 어느 시점에서 마스터 지점으로 다시 병합하려는 일부 작업을 수행했다고 가정합니다. 그 동안 마스터의 일부 버그 수정을 릴리스 브랜치로 백 포트해야합니다. 버그 수정 브랜치를 릴리즈 브랜치에 병합 할 수 있으며, 동일한 브랜치를 마스터 브랜치에 병합 할 수 있습니다 (수정이 이미 존재하더라도) 나중에 릴리스 브랜치를 다시 병합 할 때 버그 수정과 충돌이 없습니다.

마스터가 새로운 토픽 브랜치의 변경 사항을 반영하기를 원할 때 유용한 것으로 나타났습니다. -Xtheirs는 일부 상황에서 충돌없이 병합되지 않습니다. 예 :

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

생성 된 병합 커밋 확인

$ git log

이제 마스터 지점을 체크 아웃하십시오.

$ git checkout master

토픽 브랜치를 다시 병합하지만 이번에는 -Xtheirs 재귀 전략을 사용하십시오. 그러면 topicFoo 상태의 마스터 브랜치가 표시됩니다.

$ git merge -X theirs topicFoo