2012-08-30 3 views
29

우리가 공통 조상 에서 분기 한 두 가지 (BC)을 갖고 있다고 할 수 있습니다.가 C에 B에서 병합과 같은 결과를 C에 B에서 병합 할 것인가?Git에서 병합이 대칭입니까?

A 
    | 
/\ 
B C 

명확히하기 위해 수동 병합 충돌 해결이 양방향에서 발생한다고 가정합니다. 그러나 발생하는 자동 병합으로 인해 동일한 코드가 선택됩니까? 이것은 커밋 날짜가 양방향에서 동일하기 때문에 제가 가정하고있는 것입니다.

더 자세히 설명하려면 - 실제 병합은 방향에 따라 서로의 "대칭 이미지"를 생성한다는 것을 알고 있습니다. 나는 자동으로 해결 된 갈등에 대해서만 물어볼뿐입니다.

+0

Git 레코드 병합 방법이 병합의 "방향"에 어떤 영향을 주는지에 관한 관련 메일에서 Git 메일 링리스트의 3 년 된이 스레드를 찾을 수 있습니다. http : // thread .gmane.org/gmane.comp.version-control.git/127361 – seh

답변

20

기본 병합에 대한 대답은 예입니다. 3 방향 병합은 공통 조상을 찾은 다음 양측에서 차이를 적용합니다.이 작업은 순서에 종속되지 않습니다. 병합 순서와 commutativity의 주제는 git list에 대한 흥미로운 토론을 생성했습니다 (당신이 그런 종류의 사람이라면). B into CC into B은 대칭이어야하지만 (B into C) into AB into (C into A)의 경우 반드시 동일 할 필요는 없습니다.


질문에 참조 된 자동 병합 해상도에 영향을 미칠 어느 것도 B into CC into B 사이의 두 눈에 띄는 차이가있을 것입니다, 아래 빈스의 의견과 질문에 SEH의 의견에 따라, 좀 더 정교합니다.

먼저 기록이 달라집니다. 병합 커밋의 부모는 병합 순서에 따라 변경됩니다. 이 예제에서는 "first_branch"및 "second_branch"를 사용하므로 커밋을 나타내는 문자를 예약 할 수 있습니다. 이 경우

git checkout first_branch && git merge second_branch 

E <- merge commit 
|\ 
| D <- second_branch's tip 
| | 
| C <- another commit on second_branch 
| | 
| B <- and another 
|/ 
A <- first_branch's tip before the merge 

는, E, E^1의 "첫 번째 부모", 병합 전에 first_branch의 팁이다. second_branch는 병합 커밋의 두 번째 부모입니다 (별칭 : E^2). 이제 반대로 생각하십시오 :

git checkout second_branch && git merge first_branch 

E <- merge commit 
|\ 
| D <- first_branch's tip 
| | 
| C <- another commit on first_branch 
| | 
| B <- and another 
|/ 
A <- second_branch's tip before the merge 

부모는 반대입니다. E^1은 병합하기 전에 second_branch의 끝입니다. E^2은 first_branch의 팁입니다.

두 번째로, 충돌 표시 순서가 반대로됩니다.첫 번째 경우, 충돌이 다음과 같습니다

<<<<<<< HEAD 
This line was added from the second_branch branch. 
======= 
This line was added from the first_branch branch. 
>>>>>>> first_branch 

는 이러한 차이의 어느 자동 병합 해상도에 영향을 미칠하지만 :

<<<<<<< HEAD 
This line was added from the first_branch branch. 
======= 
This line was added from the second_branch branch. 
>>>>>>> second_branch 

을 두 번째 경우, 같은 충돌이 같을 것이다 3 방향 병합 순서를 되돌릴 때 나타납니다.

+0

간단한 예제를 테스트 해 보시겠습니까? 만약 당신이 병합 전략/옵션을 제공하지 않고 병합한다면 자동 호흡 (가능하다면)을 강요하고, 라인 상에 충돌이 있다면 어떻게해야할까요? '<<<<<<< yours : sample.txt 충돌 해결이 어렵습니다; 쇼핑하러 가자. ======= 힘내세요. 충돌 문제를 쉽게 해결해줍니다. >>>>>>> theirs : sample.txt'? 또는 당신은 그들 중 하나를 선택할 것인가? – Vince

+0

@Vince 내역 및 이러한 충돌이 표시되는 방식에 대한 순서는 중요하지만 자동 병합 해결 결과는 동일합니다. 자세한 내용과 몇 가지 예를 편집했습니다. – Christopher

+0

이 답변에 링크 된 토론에서 Hamano의 게시물은 읽어야합니다. http://thread.gmane.org/gmane.comp.version-control.git/107737/focus=107895 - 답변을 제공하는지 확실하지 않습니다. 그래도 질문이 –

0

아니요, 저는 이것이 대칭 적이 아닐 것이라고 생각합니다. 먼저 병합 전략 옵션을 설정할 수 있습니다. 특히 B 또는 C를 선택할지 여부를 결정하는 theirs 또는 ours을 선택하십시오.

자동 병합에서 나는 원격 브랜치가 자신의 병합에 우선 순위를 두었다 고 생각합니다. 따라서 B에서 git merge C을 호출하면 C 변경 사항이 선택됩니다. 나는 100 % 확실하지는 않습니다. 그래서 당신은 당신 자신을 시험해보고 우리에게 알려줄 수 있습니다.

+0

전략 옵션을 설정하는 명령 :'git merge -s -X

+0

일부 참조 페이지 : http://www.kernel.org/ pub/software/scm/git/docs/git-merge.html – Vince

2

"동일한 결과"가 의미하는 바에 따라 다릅니다. 콘텐츠 관점에서 충돌이 없다거나 기존의 모든 충돌이 완전히 똑같은 방식으로 해결되었다고 가정하면 결과로 생성되는 새 병합 커밋의 내용이 동일해야합니다.

그러나 기록 토폴로지 관점에서 볼 때이 두 가지는 매우 다릅니다. B 지점에 있고 C로 병합하는 경우 B의 HEAD가 병합 완결 지점을 가리 키도록 이동하지만 C 위치는 그대로 유지됩니다. 반대로 C에서 B를 병합하면 C의 HEAD가 움직이고 B는 그대로있게됩니다. 따라서 최종 토폴로지는 매우 다르므로 두 분기에서 새 커밋의 내용이 동일하더라도 두 지점 모두에서 향후 개발에 영향을 미칩니다.

관련 문제