Git 리포지토리에서 병합 충돌을 해결하는 방법

질문자 :Spoike

내 Git 리포지토리에서 병합 충돌을 해결하고 싶습니다.

어떻게 할 수 있습니까?

시도: git mergetool

각 충돌을 단계별로 안내하는 GUI가 열리고 병합 방법을 선택할 수 있습니다. 때로는 나중에 약간의 손 편집이 필요하지만 일반적으로 그 자체로 충분합니다. 확실히 모든 것을 손으로 하는 것보다 훨씬 낫습니다.

Josh Glover의 의견에 따르면:

명령

GUI를 설치하지 않는 한 반드시 GUI를 열 필요는 없습니다. 나를 위해 git mergetool 을 실행하면 vimdiff 가 사용됩니다. 다음 도구 중 하나를 설치하여 대신 사용할 수 있습니다. meld , opendiff , kdiff3 , tkdiff , xxdiff , tortoisemerge , gvimdiff , diffuse , ecmerge , p4merge , araxis , vimdiff , emerge .

다음은 병합 충돌을 해결 vimdiff 를 사용하는 샘플 절차입니다. 이 링크를 기반으로

1단계 : 터미널에서 다음 명령 실행

 git config merge.tool vimdiff git config merge.conflictstyle diff3 git config mergetool.prompt false

그러면 vimdiff가 기본 병합 도구로 설정됩니다.

2단계 : 터미널에서 다음 명령 실행

 git mergetool

3단계 : 다음 형식의 vimdiff 디스플레이가 표시됩니다.

 ╔═══════╦══════╦════════╗ ║ ║ ║ ║ ║ LOCAL ║ BASE ║ REMOTE ║ ║ ║ ║ ║ ╠═══════╩══════╩════════╣ ║ ║ ║ MERGED ║ ║ ║ ╚═══════════════════════╝

이 4가지 보기는

LOCAL – 현재 분기의 파일입니다.

BASE – 공통 조상, 두 변경 전 파일의 모습

REMOTE – 브랜치에 병합하려는 파일

MERGED – 병합 결과, 이것이 리포지토리에 저장되는 것입니다.

ctrl + w 를 사용하여 이러한 보기를 탐색할 수 있습니다. ctrl + w 다음에 j 를 사용하여 MERGED 보기에 직접 도달할 수 있습니다.

vimdiff 탐색에 대한 자세한 정보는 here 및 here 입니다.

4단계 . 다음과 같은 방법으로 병합 보기를 편집할 수 있습니다.

REMOTE에서 변경 사항을 얻으려면

 :diffg RE

BASE에서 변경 사항을 얻으려면

 :diffg BA

LOCAL에서 변경 사항을 얻으려면

 :diffg LO

5단계 . 저장, 종료, 커밋 및 정리

:wqa vi에서 저장하고 종료

git commit -m "message"

git clean diff 도구로 생성된 추가 파일(예: *.orig)을 제거합니다.

Peter Burns

위에서부터 가능한 사용 사례는 다음과 같습니다.

몇 가지 변경 사항을 가져오려고 하지만 죄송합니다. 최신 상태가 아닙니다.

 git fetch origin git pull origin master From ssh://gitosis@example.com:22/projectname * branch master -> FETCH_HEAD Updating a030c3a..ee25213 error: Entry 'filename.c' not uptodate. Cannot merge.

따라서 최신 정보를 얻고 다시 시도하지만 충돌이 발생합니다.

 git add filename.c git commit -m "made some wild and crazy changes" git pull origin master From ssh://gitosis@example.com:22/projectname * branch master -> FETCH_HEAD Auto-merging filename.c CONFLICT (content): Merge conflict in filename.c Automatic merge failed; fix conflicts and then commit the result.

따라서 변경 사항을 살펴보기로 결정합니다.

 git mergetool

앗, 맙소사, 업스트림이 몇 가지를 변경했지만 내 변경 사항을 사용하기 위해 ... 아니 ... 변경 사항이 ...

 git checkout --ours filename.c git checkout --theirs filename.c git add filename.c git commit -m "using theirs"

그런 다음 마지막 시간을 시도합니다.

 git pull origin master From ssh://gitosis@example.com:22/projectname * branch master -> FETCH_HEAD Already up-to-date.

타다!

coolaj86

병합 도구는 충돌이나 해결을 이해하는 데 거의 도움이 되지 않습니다. 나는 일반적으로 텍스트 편집기에서 충돌 마커를 보고 git log를 보완으로 사용하는 것이 더 성공적입니다.

다음은 몇 가지 팁입니다.

팁 1

내가 찾은 가장 좋은 점은 "diff3"병합 충돌 스타일을 사용하는 것입니다.

git config merge.conflictstyle diff3

이렇게 하면 다음과 같은 충돌 마커가 생성됩니다.

 <<<<<<< Changes made on the branch that is being merged into. In most cases, this is the branch that I have currently checked out (ie HEAD). ||||||| The common ancestor version. ======= Changes made on the branch that is being merged in. This is often a feature/topic branch. >>>>>>>

중간 부분은 공통 조상의 모습입니다. 이는 상위 및 하위 버전과 비교하여 각 분기에서 변경된 사항을 더 잘 파악할 수 있으므로 각 변경의 목적이 무엇인지 더 잘 알 수 있기 때문에 유용합니다.

충돌이 몇 줄에 불과한 경우 일반적으로 충돌이 매우 명확해집니다. (갈등을 해결하는 방법을 아는 것은 매우 다릅니다. 다른 사람들이 무엇을 하고 있는지 알아야 합니다. 혼란스럽다면 그 사람을 당신의 방으로 불러서 당신이 보고 있는 것을 볼 수 있도록 하는 것이 가장 좋습니다. 에.)

충돌이 더 길면 세 섹션을 각각 잘라서 "mine", "common" 및 "그들"과 같은 세 개의 개별 파일에 붙여넣습니다.

그런 다음 다음 명령을 실행하여 충돌을 일으킨 두 개의 diff 덩어리를 볼 수 있습니다.

 diff common mine diff common theirs

병합 도구에는 충돌하지 않는 diff 덩어리도 모두 포함되므로 병합 도구를 사용하는 것과는 다릅니다. 나는 그것이 산만하다고 생각합니다.

팁 2

누군가 이미 이것을 언급했지만 각 diff 덩어리의 의도를 이해하는 것은 일반적으로 충돌이 어디에서 발생하고 어떻게 처리해야 하는지 이해하는 데 매우 유용합니다.

 git log --merge -p <name of file>

이것은 공통 조상과 병합하려는 두 헤드 사이에서 해당 파일을 건드린 모든 커밋을 보여줍니다. (그래서 병합하기 전에 두 분기에 이미 존재하는 커밋은 포함하지 않습니다.) 이렇게 하면 현재 충돌의 요인이 아닌 diff 덩어리를 무시하는 데 도움이 됩니다.

팁 3

자동화된 도구로 변경 사항을 확인하십시오.

자동화된 테스트가 있는 경우 이를 실행하십시오. 보푸라기 가 있으면 실행하십시오. 빌드 가능한 프로젝트라면 커밋하기 전에 빌드하세요. 모든 경우에 변경 사항으로 인해 문제가 발생하지 않았는지 확인하기 위해 약간의 테스트를 수행해야 합니다. (젠장, 충돌이 없는 병합조차도 작동하는 코드를 깨뜨릴 수 있습니다.)

팁 4

미리 계획하십시오. 동료와 의사 소통합니다.

미리 계획하고 다른 사람들이 수행하고 있는 작업을 알고 있으면 병합 충돌을 방지하고 조기에 해결하는 데 도움이 될 수 있습니다.

예를 들어, 당신과 다른 사람이 모두 같은 파일 세트에 영향을 줄 다른 리팩토링을 작업하고 있다는 것을 알고 있다면 미리 서로 이야기하고 각자가 어떤 유형의 변경 사항인지 더 잘 이해해야 합니다. 만들기. 계획된 변경을 병렬이 아니라 직렬로 수행하면 상당한 시간과 노력을 절약할 수 있습니다.

많은 양의 코드를 가로지르는 주요 리팩토링의 경우 직렬 작업을 강력히 고려해야 합니다. 한 사람이 전체 리팩토링을 수행하는 동안 모든 사람이 해당 코드 영역에서 작업을 중지합니다.

순차적으로 작업할 수 없는 경우(아마도 시간 압박으로 인해) 예상되는 병합 충돌에 대해 통신하면 세부 사항을 아직 염두에 두고 있는 동안 문제를 더 빨리 해결하는 데 도움이 됩니다. 예를 들어, 동료가 1주일 동안 파괴적인 일련의 커밋을 수행하는 경우 해당 주 동안 매일 한 번 또는 두 번 해당 동료 브랜치를 병합/리베이스하도록 선택할 수 있습니다. 그렇게 하면 병합/리베이스 충돌을 발견하면 모든 것을 하나의 큰 덩어리로 병합하기 위해 몇 주를 기다리는 것보다 더 빨리 해결할 수 있습니다.

팁 5

병합이 확실하지 않은 경우 강제로 병합하지 마십시오.

병합은 특히 충돌하는 파일이 많고 충돌 표시가 수백 줄을 덮는 경우 압도적으로 느껴질 수 있습니다. 종종 소프트웨어 프로젝트를 추정할 때 복잡한 병합 처리와 같은 오버헤드 항목에 대한 충분한 시간을 포함하지 않기 때문에 각 충돌을 분석하는 데 몇 시간을 소비하는 것이 정말 힘들게 느껴집니다.

장기적으로, 미리 계획하고 다른 사람들이 작업하고 있는 것을 인식하는 것은 병합 충돌을 예상하고 더 짧은 시간에 올바르게 해결할 수 있도록 준비하는 가장 좋은 도구입니다.

Mark E. Haase

1. 충돌하는 파일을 식별합니다(Git에서 이를 알려야 함).

2. 각 파일을 열고 diff를 검사하십시오. Git은 이들을 구분합니다. 각 블록의 버전을 유지해야 하는 것이 분명하기를 바랍니다. 코드를 커밋한 동료 개발자와 논의해야 할 수도 있습니다.

3. 파일에서 충돌을 해결했으면 git add the_file .

4. 모든 충돌을 해결했으면 git rebase --continue 또는 완료 시 Git이 수행한 명령을 수행하십시오.

davetron5000

병합 충돌은 파일이 동시에 변경될 때 발생합니다. 해결 방법은 다음과 같습니다.

git CLI

충돌 상태가 되었을 때 수행할 간단한 단계는 다음과 같습니다.

1. git status Unmerged paths 섹션 아래)와 충돌하는 파일 목록을 확인하세요.

2. 다음 방법 중 하나를 사용하여 각 파일에 대해 개별적으로 충돌을 해결합니다.

   • GUI를 사용하여 충돌을 해결하십시오: git mergetool (가장 쉬운 방법).

   • 원격/다른 버전을 수락하려면 git checkout --theirs path/file . 그러면 해당 파일에 대해 수행한 모든 로컬 변경 사항이 거부됩니다.

   • 로컬/저희 버전을 수락하려면 다음을 사용하십시오. git checkout --ours path/file

     ^{그러나 충돌하는 원격 변경이 어떤 이유로 수행되었으므로 주의해야 합니다.}

     관련: git에서 "우리"와 "그들의"의 정확한 의미는 무엇입니까?

   • 충돌하는 파일을 수동으로 편집하고 <<<<< / >>>>> 사이의 코드 블록을 찾은 다음 위 또는 아래에서 버전을 선택하십시오 ===== . 참조: 충돌이 표시되는 방식 .

   • 경로 및 파일 이름 충돌은 git add / git rm 으로 해결할 수 있습니다.

3. git status 사용하여 커밋할 준비가 된 파일을 검토합니다.

   Unmerged paths 아래에 파일이 있고 수동으로 충돌을 해결했다면 Git에 git add path/file 통해 해결했음을 알리세요.

4. 모든 충돌이 성공적으로 해결되었으면 다음과 같이 변경 사항을 커밋합니다. git commit -a 평소처럼 원격으로 푸시합니다.

참조: GitHub 의 명령줄에서 병합 충돌 해결

실용적인 자습서를 보려면 다음을 확인하십시오. 시나리오 5 - Katacoda의 병합 충돌 수정 .

DiffMerge

Windows, macOS 및 Linux/Unix에서 파일을 시각적으로 비교하고 병합할 수 있는 DiffMerge 를 성공적으로 사용했습니다.

그것은 3개의 파일 사이의 변경 사항을 그래픽으로 표시할 수 있으며 자동 병합(안전한 경우)과 결과 파일 편집에 대한 완전한 제어를 허용합니다.

^{이미지 출처: DiffMerge (Linux 스크린샷)}

간단히 다운로드하고 repo에서 다음과 같이 실행하십시오.

 git mergetool -t diffmerge .

---

맥 OS

macOS에서는 다음을 통해 설치할 수 있습니다.

 brew install caskroom/cask/brew-cask brew cask install diffmerge

그리고 아마도 (제공되지 않은 경우) PATH에 다음과 같은 추가 간단한 래퍼가 필요합니다(예: /usr/bin ).

 #!/bin/sh DIFFMERGE_PATH=/Applications/DiffMerge.app DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge exec ${DIFFMERGE_EXE} --nosplash "$@"

그런 다음 다음 키보드 단축키를 사용할 수 있습니다.

• ⌘ - Alt - 위 / 아래 로 이전/다음 변경 사항으로 이동합니다.
• ⌘ - Alt - 왼쪽 / 오른쪽 에서 변경을 수락하려면 왼쪽 또는 오른쪽으로

또는 두 파일 또는 디렉토리를 병합하여 세 번째 파일 또는 디렉토리를 생성할 수 있는 opendiff(Xcode 도구의 일부)를 사용할 수 있습니다.

kenorb

Stack Overflow 질문 Aborting a merge in Git , 특히 문제가 있는 파일의 다른 버전을 보는 방법을 보여주는 Charles Bailey의 답변을 확인하세요. 예를 들면,

 # Common base version of the file. git show :1:some_file.cpp # 'Ours' version of the file. git show :2:some_file.cpp # 'Theirs' version of the file. git show :3:some_file.cpp

Pat Notz

git log --merge 를 사용하여 커밋 주석을 살펴보는 것으로 시작하십시오. 그런 다음 git diff 는 충돌을 보여줍니다.

몇 줄 이상을 포함하는 충돌의 경우 외부 GUI 도구에서 진행 중인 작업을 확인하는 것이 더 쉽습니다. 나는 opendiff를 좋아합니다 -- Git은 vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff도 지원하고 즉시 사용할 수 있으며 다른 것을 설치할 수 있습니다. git config merge.tool "your.tool" 은 선택한 도구를 설정한 다음 git mergetool 실패한 병합 후 컨텍스트에서 diff가 표시됩니다.

충돌을 해결하기 위해 파일을 편집할 때마다 git add filename 은 색인을 업데이트하고 diff는 더 이상 색인을 표시하지 않습니다. 모든 충돌이 처리되고 파일이 git add -ed되면 git commit 이 병합을 완료합니다.

Paul

내 버전이나 해당 버전 전체를 원하거나 개별 변경 사항을 검토하고 각각에 대해 결정하고 싶습니다.

내 또는 그들의 버전을 완전히 수락하십시오 .

내 버전 수락(로컬, 당사):

 git checkout --ours -- <filename> git add <filename> # Marks conflict as resolved git commit -m "merged bla bla" # An "empty" commit

자신의 버전(원격, 해당)을 수락합니다.

 git checkout --theirs -- <filename> git add <filename> git commit -m "merged bla bla"

모든 충돌 파일에 대해 수행하려면 다음을 실행하십시오.

 git merge --strategy-option ours

또는

 git merge --strategy-option theirs

모든 변경 사항을 검토하고 개별적으로 수락

1. git mergetool
2. 변경 사항을 검토하고 각각에 대해 두 버전 중 하나를 수락합니다.
3. git add <filename>
4. git commit -m "merged bla bla"

기본 mergetool 은 명령줄 에서 작동합니다. 명령줄 mergetool을 사용하는 방법은 별도의 질문이어야 합니다.

이를 위한 시각적 도구( meld 및 실행)를 설치할 수도 있습니다.

 git mergetool -t meld

로컬 버전(우리), "기본" 또는 "병합" 버전(병합의 현재 결과) 및 원격 버전(해당)이 열립니다. 완료되면 병합된 버전을 저장하고 "파일 병합 필요 없음"이 표시될 때까지 git mergetool -t meld

Noidea

병합 충돌 표시가 무엇인지 이해하려면 충돌이 표시되는 방법 또는 Git의 git merge 문서를 참조하십시오.

또한 충돌을 해결 하는 방법 섹션에서는 충돌을 해결하는 방법을 설명합니다.

충돌을 확인한 후 다음 두 가지 작업을 수행할 수 있습니다.

• 병합하지 않기로 결정합니다. 필요한 유일한 정리는 인덱스 파일을 HEAD 커밋으로 재설정하여 2.와 2. 및 3.에 의해 수행된 작업 트리 변경 사항을 정리하는 것입니다. git merge --abort 사용할 수 있습니다.

• 충돌을 해결합니다. Git은 작업 트리에서 충돌을 표시합니다. 파일을 모양으로 편집하고 git add 이 인덱스에 추가합니다. git commit 을 사용하여 거래를 봉인하십시오.

다음과 같은 여러 도구를 사용하여 충돌을 해결할 수 있습니다.

• 병합 도구를 사용하십시오. git mergetool 병합을 통해 작업할 그래픽 병합 도구를 시작합니다.

• 차이점을 보세요. git diff HEAD 및 MERGE_HEAD 버전의 변경 사항을 강조 표시하는 3방향 diff를 표시합니다.

• 각 지점의 차이점을 살펴보십시오. git log --merge -p <path> HEAD 버전에 대한 diff를 표시 MERGE_HEAD 버전을 표시합니다.

• 원본을 보세요. git show :1:filename 은 공통 조상을 git show :2:filename 은 HEAD 버전을 git show :3:filename MERGE_HEAD 버전을 보여줍니다.

또한 Pro Git 책 섹션 Basic Merge Conflicts 에서 병합 충돌 표시와 이를 해결하는 방법에 대해 읽을 수 있습니다.

user456814

병합 충돌을 반 수동으로 해결하려는 Emacs 사용자의 경우:

 git diff --name-status --diff-filter=U

충돌 해결이 필요한 모든 파일을 표시합니다.

다음과 같이 각 파일을 하나씩 열거나 한 번에 모두 엽니다.

 emacs $(git diff --name-only --diff-filter=U)

Emacs에서 편집이 필요한 버퍼를 방문할 때 다음을 입력하십시오.

 ALT+x vc-resolve-conflicts

이렇게 하면 세 개의 버퍼(광산, 해당 버퍼, 출력 버퍼)가 열립니다. 'n'(다음 영역), 'p'(사전 영역)를 눌러 탐색합니다. 'a' 및 'b'를 눌러 광산 또는 해당 영역을 각각 출력 버퍼에 복사합니다. 및/또는 출력 버퍼를 직접 편집합니다.

완료되면 'q'를 누릅니다. Emacs는 이 버퍼를 저장할 것인지 묻습니다: 예. 버퍼를 완료한 후 터미널에서 실행하여 해결된 것으로 표시합니다.

 git add FILENAME

모든 버퍼 유형으로 완료되면

 git commit

병합을 완료합니다.

eci

보너스:

이전 답변에서 pull/fetch/merge에 대해 이야기하면서 흥미롭고 생산적인 트릭을 공유하고 싶습니다.

git pull --rebase

위 명령어는 제 Git 생활에서 가장 많은 시간을 절약해 준 가장 유용한 명령어입니다.

새로 커밋된 변경 사항을 원격 서버로 푸시하기 전에 git pull --rebase 대신 git pull 및 manual merge 시도하면 최신 원격 서버 변경 사항(fetch + merge 사용)이 자동으로 동기화되고 로컬 최신 커밋이 맨 위에 놓입니다. 힘내 로그. 수동 pull/merge에 대해 걱정할 필요가 없습니다.

충돌이 발생하면 다음을 사용하십시오.

 git mergetool git add conflict_file git rebase --continue

"git pull –rebase"의 기능은 무엇입니까?

Sazzad Hissain Khan

간단히 말해서, 리포지토리 중 하나의 변경 사항이 중요하지 않다는 것을 잘 알고 있고 다른 리포지토리를 위해 모든 변경 사항을 해결하려면 다음을 사용하십시오.

 git checkout . --ours

저장소에 유리하게 변경 사항을 해결하거나

 git checkout . --theirs

다른 저장소나 주 저장소 를 위해 변경 사항을 해결합니다.

또는 GUI 병합 도구를 사용하여 파일을 하나씩 단계별로 실행해야 합니다. 병합 도구가 p4merge 라고 말하거나 이미 설치한 사람의 이름을 작성해야 합니다.

 git mergetool -t p4merge

파일을 완성한 후에는 저장하고 닫아야 다음 파일이 열립니다.

Mohamed

Git에서 병합 충돌을 수정하려면 다음 단계를 따르세요.

1. Git 상태 확인: git status

2. 패치 세트 가져오기 : git fetch(Git 커밋에서 올바른 패치 확인)

3. 로컬 브랜치를 체크아웃하십시오(여기 내 예에서는 temp1): git checkout -b temp1

4. 마스터에서 최근 내용 가져오기: git pull --rebase origin master

5. mergetool을 시작하고 충돌을 확인하고 수정하십시오... 그리고 현재 브랜치로 원격 브랜치의 변경 사항을 확인하십시오: git mergetool

6. 상태를 다시 확인하십시오. git status

7. mergetool에 의해 로컬로 생성된 원치 않는 파일을 삭제합니다. 일반적으로 mergetool은 *.orig 확장자를 가진 추가 파일을 생성합니다. 중복 파일일 뿐이므로 해당 파일을 삭제하고 로컬에서 변경 사항을 수정하고 올바른 버전의 파일을 추가하십시오. git add #your_changed_correct_files

8. 상태를 다시 확인하십시오. git status

9. 변경 사항을 동일한 커밋 ID에 커밋합니다(이렇게 하면 새로운 별도의 패치 세트를 피할 수 있음): git commit --amend

10. 마스터 브랜치로 푸시: git push (Git 저장소로)

Chhabilal

세 단계가 있습니다.

1. 명령으로 충돌을 일으키는 파일 찾기

    git status

2. 다음과 같이 표시된 충돌이 있는 파일을 확인하십시오.

    <<<<<<<<head blablabla

3. 원하는 방식으로 변경한 다음 명령으로 커밋합니다.

    git add solved_conflicts_files git commit -m 'merge msg'

Qijun Liu

다른 사람이 자세히 설명한 것처럼 여러 가지 방법으로 병합 충돌을 수정할 수 있습니다.

진정한 열쇠는 변경 사항이 로컬 및 원격 리포지토리와 함께 흐르는 방식을 아는 것이라고 생각합니다. 이에 대한 핵심은 분기 추적을 이해하는 것입니다. 나는 추적 분기를 내 로컬의 실제 파일 디렉토리와 원점으로 정의된 원격 사이의 '중간에 누락된 부분'으로 생각한다는 것을 발견했습니다.

저는 개인적으로 이것을 피하기 위해 2가지 습관을 들이고 있습니다.

대신에:

 git add . git commit -m"some msg"

두 가지 단점이 있습니다 -

) 모든 신규/변경된 파일이 추가되며 여기에는 원치 않는 변경 사항이 포함될 수 있습니다.
b) 파일 목록을 먼저 검토할 수 없습니다.

그래서 대신 나는 :

 git add file,file2,file3... git commit # Then type the files in the editor and save-quit.

이렇게 하면 추가할 파일에 대해 더 신중하게 생각하고 목록을 검토하고 메시지 편집기를 사용하는 동안 조금 더 생각할 수 있습니다. -m 옵션이 아닌 전체 화면 편집기를 사용할 때 커밋 메시지도 향상됩니다.

[업데이트 - 시간이 지남에 따라 다음으로 더 많이 전환했습니다.

 git status # Make sure I know whats going on git add . git commit # Then use the editor

]

또한 (귀하의 상황과 더 관련이 있음) 다음을 피하려고 합니다.

 git pull

또는

 git pull origin master.

pull은 병합을 의미하고 병합을 원하지 않는 로컬 변경 사항이 있는 경우 병합되지 않아야 하는 코드에 대해 병합된 코드 및/또는 병합 충돌로 쉽게 끝날 수 있기 때문입니다.

대신 나는 하려고 노력한다

 git checkout master git fetch git rebase --hard origin/master # or whatever branch I want.

다음이 도움이 될 수도 있습니다.

git 분기, 포크, 가져오기, 병합, 리베이스 및 복제, 차이점은 무엇입니까?

Michael Durrant

CoolAJ86의 답변은 거의 모든 것을 요약합니다. 동일한 코드 조각에서 두 분기에 변경 사항이 있는 경우 수동 병합을 수행해야 합니다. 텍스트 편집기에서 충돌하는 파일을 열면 다음 구조가 표시되어야 합니다.

 (Code not in Conflict) >>>>>>>>>>> (first alternative for conflict starts here) Multiple code lines here =========== (second alternative for conflict starts here) Multiple code lines here too <<<<<<<<<<< (Code not in conflict here)

등호와 꺾쇠 괄호를 제거하면서 새 코드를 원하는 방식으로 대안 중 하나 또는 둘의 조합을 선택합니다.

 git commit -a -m "commit message" git push origin master

iankit

test 에서 master 로 병합하려면 다음 단계를 따르세요.

1단계 : 지점으로 이동

 git checkout test

2단계 :

 git pull --rebase origin master

3단계 : 충돌이 있는 경우 이 파일로 이동하여 수정합니다.

4단계 : 이러한 변경 사항 추가

 git add #your_changes_files

5단계 :

 git rebase --continue

6단계 : 여전히 충돌이 있으면 3단계로 다시 돌아갑니다. 충돌이 없으면 다음을 수행하십시오.

 git push origin +test

7단계 : 그리고 테스트와 마스터 간에 충돌이 없습니다. 병합을 직접 사용할 수 있습니다.

Haimei

git log --merge -p [[--] path]

항상 나를 위해 작동하는 것 같지 않으며 일반적으로 두 분기 간에 다른 모든 커밋을 표시하게 됩니다. 이는 명령에서 경로를 분리하기 위해 --

이 문제를 해결하기 위해 내가 하는 일은 두 개의 명령줄을 열고 한 번에 실행하는 것입니다.

 git log ..$MERGED_IN_BRANCH --pretty=full -p [path]

그리고 다른 곳에서

 git log $MERGED_IN_BRANCH.. --pretty=full -p [path]

$MERGED_IN_BRANCH 를 내가 병합한 분기로 대체 [path] 를 충돌하는 파일로 대체합니다. .. ) 두 커밋 사이의 모든 커밋을 패치 형식으로 기록합니다. 위의 명령과 같이 한 쪽을 비워두면 git은 자동으로 HEAD (이 경우 병합하려는 분기)를 사용합니다.

이렇게 하면 분기된 후 두 분기의 파일에 어떤 커밋이 들어갔는지 확인할 수 있습니다. 일반적으로 충돌을 훨씬 쉽게 해결할 수 있습니다.

Brian Di Palma

patience 사용

큰 병합 충돌의 경우 patience 사용하면 좋은 결과를 얻을 수 있습니다. 개별 라인이 아닌 블록을 일치시키려고 합니다.

예를 들어 프로그램의 들여쓰기를 변경하면 기본 Git 병합 전략이 다른 기능에 속하는 { patience 을 가지고 피할 수 있습니다.

 git merge -s recursive -X patience other-branch

문서에서:

 With this option, merge-recursive spends a little extra time to avoid mismerges that sometimes occur due to unimportant matching lines (eg, braces from distinct functions). Use this when the branches to be merged have diverged wildly.

공통 조상과의 비교

병합 충돌이 있고 다른 사람들이 자신의 분기를 수정할 때 염두에 두었던 내용을 확인하려는 경우 해당 분기를 (우리 분기 대신) 공통 조상과 직접 비교하는 것이 더 쉬울 때가 있습니다. merge-base 사용할 수 있습니다.

 git diff $(git merge-base <our-branch> <their-branch>) <their-branch>

일반적으로 특정 파일에 대한 변경 사항만 보고자 합니다.

 git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>

Conchylicultor

2016년 12월 12일부터 github.com에서 브랜치를 병합하고 충돌을 해결할 수 있습니다.

따라서 이전 답변에서 제공되는 명령줄 또는 타사 도구를 사용하지 않으려면 GitHub의 기본 도구를 사용하세요.

이 블로그 게시물 에서 자세히 설명하지만 기본 사항은 UI를 통해 두 분기를 '병합'하면 이러한 병합 충돌을 처리할 수 있는 편집기로 이동하는 '충돌 해결' 옵션이 표시된다는 것입니다.

maxwell

나는 항상 충돌을 피하기 위해 아래 단계를 따릅니다.

• git checkout master (마스터 브랜치로 오세요)
• git pull (최신 코드를 얻으려면 마스터 업데이트)
• git checkout -b mybranch (새 a 브랜치를 확인하고 해당 브랜치에서 작업을 시작하여 마스터가 항상 트렁크의 맨 위에 있도록 합니다.)
• git add . 및 git commit 및 git push (변경 후 로컬 분기에서)
• git checkout master (마스터에게 돌아가기)

이제 필요할 때마다 분기에 git checkout 을 수행하여 동일한 작업을 수행하고 원하는 만큼 로컬 분기를 유지하고 동시에 작업할 수 있습니다.

Chetan

병합 충돌은 다음과 같은 다양한 상황에서 발생할 수 있습니다.

• git fetch 실행한 다음 git merge 를 실행할 때
• git fetch 실행한 다음 git rebase 를 실행할 때
• git pull 실행할 때(실제로 위에서 언급한 조건 중 하나와 동일)
• git stash pop 실행할 때
• git 패치를 적용하는 경우(예: 이메일로 전송할 파일로 내보내는 커밋)

충돌을 해결하려면 Git과 호환되는 병합 도구를 설치해야 합니다. 저는 개인적으로 KDiff3 을 사용하는데, 그것이 훌륭하고 편리하다는 것을 알았습니다. 여기에서 Windows 버전을 다운로드할 수 있습니다.

https://sourceforge.net/projects/kdiff3/files/

BTW, Git Extensions를 설치하면 설치 마법사에 Kdiff3을 설치하는 옵션이 있습니다.

그런 다음 KDiff3을 병합 도구로 사용하도록 Git 구성을 설정합니다.

 $ git config --global --add merge.tool kdiff3 $ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe" $ git config --global --add mergetool.kdiff3.trustExitCode false $ git config --global --add diff.guitool kdiff3 $ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe" $ git config --global --add difftool.kdiff3.trustExitCode false

(경로를 KDiff3 EXE 파일의 실제 경로로 바꾸는 것을 잊지 마십시오.)

그런 다음 병합 충돌이 발생할 때마다 다음 명령을 실행하기만 하면 됩니다.

 $ git mergetool

그런 다음 Kdiff3을 열고 먼저 병합 충돌을 자동으로 해결하려고 시도합니다. 대부분의 충돌은 자발적으로 해결되며 나머지는 수동으로 수정해야 합니다.

다음은 Kdiff3의 모습입니다.

그런 다음 완료되면 파일을 저장하고 충돌이 있는 다음 파일로 이동하고 모든 충돌이 해결될 때까지 동일한 작업을 다시 수행합니다.

모든 것이 성공적으로 병합되었는지 확인하려면 mergetool 명령을 다시 실행하십시오. 다음과 같은 결과를 얻어야 합니다.

 $ git mergetool No files need merging

akazemis

이 답변은 편집기 내에서 모든 작업을 수행하는 것을 선호하는 저와 같은 Vim 사용자를 위한 대안을 추가하는 것입니다.

---

TL;DR

---

Tpope 는 fugitive 라는 Vim용 플러그인을 만들었습니다. 설치 후에는 실행할 수 있습니다 :Gstatus 갈등을 가지고있는 파일을 확인 :Gdiff 열고 힘내에 세 방향 병합에.

3방향 병합이 완료되면 fugitive를 사용 하면 병합하려는 분기의 변경 사항을 다음과 같은 방식으로 가져올 수 있습니다.

• :diffget //2 , 원본( HEAD ) 분기에서 변경 사항을 가져옵니다.
• :diffget //3 , 병합 분기에서 변경 사항 가져오기:

파일 병합이 완료되면 병합된 버퍼에 :Gwrite

Vimcasts는 이러한 단계를 자세히 설명 하는 훌륭한 비디오를 발표했습니다.

Vicente Bolea

Visual Studio 코드용 GitLens

Visual Studio Code용 GitLens 를 사용해 볼 수 있습니다. 주요 기능은 다음과 같습니다.

3. 갈등을 쉽게 해결

나는 이미 이 기능을 좋아합니다:

2. 현재 라인 비난.

3. 거터 비난

4. 상태 표시줄 비난

그리고 많은 기능이 있습니다. 여기에서 확인할 수 있습니다.

Ilyas karim

git fetch <br> git checkout **your branch**<br> git rebase master<br>

이 단계에서는 선호하는 IDE를 사용하여 충돌을 해결하려고 합니다.

이 링크 를 따라 파일의 충돌을 수정하는 방법을 확인할 수 있습니다.

 git add<br> git rebase --continue<br> git commit --amend<br> git push origin HEAD:refs/drafts/master (push like a drafts)<br>

이제 모든 것이 정상 이며 Gerrit에서 커밋을 찾을 수 있습니다.

Baini.Marouane

병합 충돌이 무엇인지 이해했지만 git diff 의 출력을 보았을 때 처음에는 말도 안되는 것처럼 보였습니다.

 git diff ++<<<<<<< HEAD + display full last name boolean in star table ++======= + users viewer.id/star.id, and conversation uses user.id + ++>>>>>>> feat/rspec-tests-for-cancancan

그러나 여기 에 도움이 된 것이 있습니다.

• <<<<<<< 와 ======= 사이의 모든 것은 하나의 파일에 있던 것입니다.

• ======= 와 >>>>>>> 사이의 모든 것은 다른 파일에 있던 것입니다.

• 따라서 말 그대로 병합 충돌이 있는 파일을 열고 두 분기에서 해당 줄을 제거하거나 동일하게 만들기만 하면 merge 이 즉시 성공합니다. 문제 해결됨!

stevec

충돌을 해결하는 더 안전한 방법은 git-mediate 를 사용하는 것입니다(여기에 제안된 일반적인 솔루션은 오류가 발생하기 쉽습니다).

사용 방법에 대한 빠른 소개는 이 게시물 을 참조하세요.

yairchu

Visual Studio를 사용하는 사람들을 위해(내 경우에는 Visual Studio 2015)

1. Visual Studio에서 프로젝트를 닫습니다. 특히 대규모 프로젝트에서 Visual Studio는 UI를 사용하여 병합할 때 놀라는 경향이 있습니다.

2. 명령 프롬프트에서 병합을 수행하십시오.

   자식 체크 아웃 target_branch

   자식 병합 source_branch

3. 그런 다음 Visual Studio에서 프로젝트를 열고 Team Explorer → Branch 로 이동합니다. 이제 병합이 보류 중이고 충돌하는 파일이 메시지 바로 아래에 나열된다는 메시지가 표시됩니다.

4. 충돌하는 파일을 클릭하면 병합 , 비교 , 원본 가져오기 및 대상 가져오기 옵션이 표시됩니다. Visual Studio의 병합 도구는 사용하기가 매우 쉽습니다.

Miguel

아직 편집하지 않은 경우 Visual Studio Code를 사용하여 편집해 보십시오.

병합을 시도한 후(그리고 병합 충돌이 발생한 경우) Visual Studio Code는 자동으로 병합 충돌을 감지합니다.

원래 변경 사항을 표시하고 incoming 또는

current change (병합 전의 원래 변경 사항을 의미)'.

그것은 나를 도왔고 당신에게도 도움이 될 수 있습니다!

추신: 코드 및 Visual Studio Code로 Git을 구성한 경우에만 작동합니다.

Kailash Bhalaki

충돌을 해결하기 위해 Microsoft의 Visual Studio Code를 사용하고 있습니다. 사용 방법은 매우 간단합니다. 작업 공간에서 프로젝트를 열어 둡니다. 충돌을 감지하고 강조 표시합니다. 또한 HEAD 또는 수신에서 유지하려는 변경 사항을 선택할 수 있는 GUI 옵션을 제공합니다.

Ammar Mujeeb

출처 : 여기를 클릭하세요

출처 : http:www.stackoverflow.com/questions/161813/how-to-resolve-merge-conflicts-in-a-git-repository