리베이스를 수행하고 바이너리 파일에 대해 "both added"충돌이 발생합니다. 바이너리 파일이 같으면 'ours'를 받아들이겠습니다. 바뀐 파일은 'theirs'입니다. 해결하는 동안 바이너리 파일이 동일하거나 다른지 어떻게 테스트 할 수 있습니까?"both added"git conflict를 해결하는 동안 바이너리 파일이 변경되었는지 확인
0
A
답변
1
파일이 일치해도 충돌이 발생하지 않습니다.
예를 들어 설명해보기로하겠습니다.
$ mkdir addadd; cd addadd; git init
Initialized empty Git repository in /home/torek/tmp/addadd/.git/
$ echo a repository for testing add/add conflict > README
$ git add README
$ git commit -m initial
[master (root-commit) f665e86] initial
1 file changed, 1 insertion(+)
create mode 100644 README
이제 우리는 어떤 바이너리 파일이 필요합니다 : 당신이 REBASE (병합 대)에 대해 이야기하고 있지만이 포함 된 동일한 코드는 이후, 충돌, 같은 방식으로 처리됩니다. 나는
/bin/ls
과
/bin/cat
을 사용하고 두 개 더 가지로 하나의 이름 아래 두 가지로 하나의 이름 아래에 동일한 바이너리를두고, 동일하지 않은 버전이됩니다
$ git checkout -b b1 master
Switched to a new branch 'b1'
$ cp /bin/ls some-file
$ git add some-file && git commit -m 'add some-file on b1'
[b1 5128ae4] add some-file on b1
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100755 some-file
$ git checkout -b b2 master
Switched to a new branch 'b2'
$ cp /bin/ls some-file
$ git add some-file && git commit -m 'add some-file on b2'
[b2 0e7d771] add some-file on b2
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100755 some-file
이제 우리는
b2
또는 그 반대의 경우도 마찬가지로
b1
을 병합하려고합니다. 우리는 이미
b2
에있어 그래서 여기
b1
를 병합하자
$ git merge --no-edit b1
Merge made by the 'recursive' strategy.
$ git log --oneline --decorate --graph --all
* 257e77a (HEAD -> b2) Merge branch 'b1' into b2
|\
| * 5128ae4 (b1) add some-file on b1
* | 0e7d771 add some-file on b2
|/
* f665e86 (master) initial
을 이제 다른 바이너리와 같은 일을 해보자 :
$ git checkout -b b3 master
Switched to a new branch 'b3'
$ cp /bin/ls some-file
$ git add some-file && git commit -m 'add some-file on b3'
[b3 2ede434] add some-file on b3
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100755 some-file
$ git checkout -b b4 master
Switched to a new branch 'b4'
$ cp /bin/cat some-file
$ git add some-file && git commit -m 'add different some-file on b4'
[b4 9e5f2cf] add different some-file on b4
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100755 some-file
을 다시 말하지만, 우리가 여기 b4
에 b3
를 병합 할 수 있습니다 :
$ git merge --no-edit b3
warning: Cannot merge binary files: some-file (HEAD vs. b3)
Auto-merging some-file
CONFLICT (add/add): Merge conflict in some-file
Automatic merge failed; fix conflicts and then commit the result.
$ git status --short
AA some-file
이번에는 병합이 추가/추가 충돌로 실패했습니다. 즉, 파일이 다르다는 것을 의미합니다. 파일이 동일하기 때문에 이전 병합이 성공했습니다. 병합이 완료되지하지만이 그래프 커밋에서 우리는 여전히 볼 수 있습니다 : 파일이 동일한 경우
흥미롭게$ git log --oneline --decorate --graph --all
* 9e5f2cf (HEAD -> b4) add different some-file on b4
| * 2ede434 (b3) add some-file on b3
|/
| * 257e77a (b2) Merge branch 'b1' into b2
| |\
| | * 5128ae4 (b1) add some-file on b1
| |/
|/|
| * 0e7d771 add some-file on b2
|/
* f665e86 (master) initial
, 우리는 심지어 경고 메시지가 표시되지 않습니다를. Git의 병합 기계가 파일이 일치 할 때 모든 일반적인 병합 코드를 무시하기 때문입니다. 특히, .gitattributes
파일의 사용자 지정 병합 드라이버는 실행되지 않습니다.
우리는 파일이 다른 (그리고이 있었다는 것을 추가가/충돌을 추가) git ls-files --stage
을 실행하여 볼 수 있습니다 some-file
는 단계 2와 3으로 존재
$ git ls-files --stage
100644 661d9d91972de27e4f787e3ad93ea3b7a1741ddf 0 README
100755 b75a044e06fb5e093a547c4ef9a388313d27f79a 2 some-file
100755 2ca93e76b4dedc9970cca9a708ab1cb94ca032ee 3 some-file
경로 이름,하지만 1 단계 (기본)로 . 즉, 파일의 기본 버전이 없음을 의미하므로 추가/추가 충돌입니다. 단계 2 --ours
해시는 b75a044...
이며, 단 3 --theirs
해시 우리는 git rev-parse
으로 볼 수있는, 2ca93e7...
이다
$ git rev-parse :2:some-file
b75a044e06fb5e093a547c4ef9a388313d27f79a
(원하는 경우 :3:some-file
를 반복).
1 더 정확하게, 힘내는 단순히 인덱스 항목의 해시 다른에 해시 일치 또는 --theirs
커밋 여부를 확인합니다. 그렇다면 정의에 따라 동일한 파일이며 병합 작업이 필요하지 않습니다.
동일하면 왜 찍은 것이 중요할까요? – jthill