5장. 머지, 풀, 컨플릭트
머지(Merge)는 따로 작업하던 브렌치를 다시 한 길로 합치는 행동입니다.
풀(Pull)은 한 번에 2가지를 하는 동작입니다. 즉 Pull = Fetch + Merge입니다.
컨플릭트(conflict)는 같은 부분을 서로 다르게 고쳐서, Git이 자동으로 어느 쪽을 남겨야 할지 판단하지 못할 때 발생합니다.
4장에서 이어서: Fetch 다음에는?
4장에서 본 흐름처럼, 먼저 Fetch로 origin/main이 최신으로 갱신됩니다. 이때 내 작업 위치(HEAD)는 보통 main에 그대로 있습니다.
그다음 단계가 Merge입니다. 즉 main에 origin/main을 합칩니다. 이 Merge 단계에서 같은 줄을 다르게 고쳤다면 컨플릭트가 발생할 수 있습니다.
그림 5-1. 브렌치 머지
feature에서 작업한 내용을 main으로 합치면 머지 커밋이 생깁니다.
그림 5-2. Pull 시나리오 A: 내 로컬 변경이 없는 경우
Fetch로 origin/main만 먼저 앞선 뒤, Pull 하면 main이 빠르게 같은 지점으로 이동합니다.
이 경우에는 별도 Merge 커밋이 생기지 않습니다. (이걸 "fast-forward" 라고 불러요)
그림 5-3. Pull 시나리오 B: 내 로컬 변경이 있는 경우
내 main에도 커밋이 있으면 Pull 과정에서 Merge 단계가 필요합니다.
origin/main은 그대로 표시되고, Fetch로 받은 원격 변경은 origin/main의 분기로 나타납니다.
같은 줄을 다르게 고쳤다면 컨플릭트를 해결한 뒤 Merge 커밋으로 마무리됩니다.
컨플릭트가 났을 때 기본 순서
- 무엇이 서로 다른지 줄 단위로 확인한다.
- 팀 기준에 맞는 최종 문장을 고른다.
- 고른 내용으로 정리한 뒤 다시 커밋한다.
- 작업자가 이해할 수 있는 짧은 설명을 남긴다.
여기까지 이해했다면, 다음 장에서 "이 머지 과정을 팀 검토 절차(PR)로 운영하면 어떻게 되는지"를 이어서 볼 수 있습니다.