3-way merge

예시

기반 커밋	커밋1	커밋2	머지 커밋
A	A
B	B	B	B
C	Ca	Cb	충돌 발생
D		D

위 표는 커밋1과 커밋2를 병합하려고 하는데, 두 커밋의 공통된 기반 커밋을 참고하여 어떤 것을 머지 커밋에 채택할지 결정하고 있다. 이런 방식을 3-way merge라고 부른다.

 

위 표를 보면 기반 커밋이 A파일을 가지고 있고, 커밋1 또한 A파일을 가지고 있는데 커밋2는 A파일을 가지고 있지 않다.

이 말은 즉슨 커밋1에서는 A파일에 대한 수정이 일어나지 않았지만 커밋2에서는 A파일을 삭제했다는 뜻이 되므로 두 커밋을 병합할 때 우선시해야 할 수정사항은 A파일의 삭제가 된다.

 

두 번째로 기반 커밋과 커밋1, 커밋2 모두 B파일을 가지고 있고 이는 아무런 변화도 일어나지 않음을 뜻하므로 병합할 때 또한 B파일은 그대로 유지되게 된다.

 

세 번째로 기반 커밋이 C파일을 가지고 있고, 커밋1은 C파일을 수정한 Ca파일을, 커밋2는 C파일을 수정한 Cb파일을 가지고 있다. 이 경우 커밋1과 커밋2 둘 다 변경이 일어났으므로 Git은 어떤 수정사항을 적용할지 알 수 없으므로 충돌이 발생하고 어떤 수정을 적용할지 개발자에게 맡기게 된다.

 

네 번째 경우엔 첫 번째 경우와 같이 기반 커밋이 가지고 있던 D파일을 커밋2는 그대로 가지고 있지만 커밋1은 삭제가 이루어졌으므로 병합할 때 D파일을 삭제하게 된다.

 

 

결론

위 경우들에게서 얻을 수 있는 결론은 Git이 3-way merge를 진행할 때 기반 커밋에서 수정된 커밋을 우선시하고, 만약 두 커밋 모두에게서 수정이 일어났다면 충돌이 발생하고 개발자가 대신 처리해주어야 한다는 것이다.