기본 병합에 대한 대답은 예입니다. 3 방향 병합은 공통 조상을 찾은 다음 양측에서 차이를 적용합니다.이 작업은 순서에 종속되지 않습니다. 병합 순서와 commutativity의 주제는 git list에 대한 흥미로운 토론을 생성했습니다 (당신이 그런 종류의 사람이라면). B into C
과 C into B
은 대칭이어야하지만 (B into C) into A
대 B into (C into A)
의 경우 반드시 동일 할 필요는 없습니다.
질문에 참조 된 자동 병합 해상도에 영향을 미칠 어느 것도
B into C
과
C 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 방향 병합 순서를 되돌릴 때 나타납니다.
Git 레코드 병합 방법이 병합의 "방향"에 어떤 영향을 주는지에 관한 관련 메일에서 Git 메일 링리스트의 3 년 된이 스레드를 찾을 수 있습니다. http : // thread .gmane.org/gmane.comp.version-control.git/127361 – seh