프로젝트 중 github merge conflict 중에 생긴 문제
팀원이 작업물을 merge하려는데 conflict가 발생했는데 vscode에서 3가지 선택사항을 hint로 내주었다. 다만 나같은 경우에는 처음 설정한 값이 있었는지 이런 현상을 겪지 못해서 어떤 내용인지 모르고 튜터님께 도움을 받아 해결을 했다. 그러는 김에 3가지 선택사항이 어떤 차이점이 있는지도 정리해보려 한다. 일단 제시된 힌트는 다음과 같다.
- git config pull.rebase false #merge
- git config pull.rebase true #rebase
- git config pull.ff only #fast-forward only
사실 merge하려는 결과물이 동일하다면 눈에 보이는 최종 merge 결과물은 동일할 가능성이 높다. 하지만 3가지의 차이점은 커밋 내역에서 차이가 있다는 것이다.
- 우선 fast forward 방식은 분기된 branch가 main의 커밋 내역을 포함하고 있고 그 상태에서 test 브랜치가 커밋을 한번 더 했기 때문에, main의 내용이 변경되지 않은 상태에서 실행하는 브랜치의 Head Commit이 병합 되는 main의 Head commit으로 이동되는 방식을 Fast-forward 방식 병합이라고 한다.(뒤쳐져 있는 main을 빨리 감기하여 통합시키는 것이라고 이해할 수도 있다.)
main : 커밋 A -> 커밋 B (head)
test : main의 head인 커밋 B에서 파생된 커밋 C -> 커밋 D
결과 : A -> B -> C -> D
- 다만 실제 프로젝트에서는 main에서 여러개의 branch가 분기되거나 main에서 새로운 merge commit이 진행된 이후 그 위치에 새롭게 생긴 head에서 분기된 branch가 있을 수도 있기에 fast forward 방식이 작동하지 않을 가능성이 매우 높다. 그렇기에 rebase와 merge 방식이 사용되는 것이라 생각되는데, rebase 방식은 간단하게 말하면 현재 작업하는 브랜치에서 대상 브랜치를 base로 해서 커밋 이력을 재정렬한다고 볼 수 있다. 즉, rebase란 현재 작업하는 브랜치를 병합 대상 브랜치의 head로 부터 분기된 브랜치로 간주하겠다는 뜻도 된다.
main : 커밋 A -> 커밋 B (test가 분기할 시점의 head) -> 커밋 C (커밋 이후 main의 head)
test : 커밋 D -> 커밋 E -> 커밋 F
결과 : A -> B -> C -> D' -> E' -> F'
test가 main의 커밋 내역을 이제 온전히 포괄하고 있지 못하기 때문에 main의 커밋 진행이 완료되었다면 B와 C의 사이에 test의 커밋이 들어갈 수 없게 된다. 그렇기에 새롭게 생성된 main의 head를 base로 하여(rebase) 그 이후에 새로운 커밋 D',E',F'를 붙여주는 것이다.(표기에서 알 수 있듯이 test의 커밋 D,E,F 와는 내용은 같을 지언정 다른 커밋 로그라고 생각해야 한다.)
.