머지(Merge)는 일정한 규칙을 가지고 이루어지는데, 이 규칙에 따라 두가지 종류로 나눌 수 있다. 오늘은 이러한 머지의 규칙과 종류에 대해서 포스팅해보려고 한다.
머지(Merge)의 규칙
머지를 할 때 컨플릭트(Conflict)가 발생하는 경우가 종종 있다. 컨플릭트가 발생하는 이유에 대해서는 이미 알고 있지만, 그렇다면 git은 어떤 규칙으로 파일을 합치는 것일까? 머지는 아래 두가지 규칙에 따라 이루어진다고 한다.
- 브랜치의 가지가 갈라져 나온 시점의 커밋 내용과 비교했을 때, 달라진 부분이 있다면 우선하여 적용
- 만약 두 브랜치에서 동일한 부분에 변화가 있다면, git은 어떤 것을 우선시해야 할지 판단하지 못함 → 컨플릭트를 발생시켜서 사용자가 직접 선택하도록 유도
머지(Merge)의 종류
위의 규칙에 따라 머지는 두가지 경우의 수로 발생할 수 있다. 상황에 따라서 Fast-forward Merge와 3-way Merge라고 부르는데, 아래에 이해를 돕기 위한 그림을 첨부했다.
Fast-forward Merge
머지를 실행했는데 합치려는 브랜치가 동일선상에 있는 경우이다. 브랜치의 가지가 갈라져 나온 시점의 커밋을 Base라고 할 때, A 브랜치와 비교했을 때에는 달라진 부분이 없는데, B 브랜치와 비교했을 때에는 달라진 부분이 있다.
머지는 Base와 비교하여 변화된 부분이 있으면 그것을 우선시하므로, 아래와 같이 A, B 브랜치가 동일한 커밋에 위치하게 된다. (새로운 머지 커밋이 생기지 않음)
3-way Merge
머지를 실행하는데 합치려는 브랜치가 각각 다른 작업을 수행했을 경우이다. 이럴 때에 git은 Base, A 브랜치, B 브랜치의 커밋 상태를 모두 비교한다. Base 브랜치와 비교하여 변화가 일어난 부분이 서로 겹치지 않으면, git은 브랜치 내용을 모두 합쳐 새로운 머지 커밋을 만든다. (커밋 성공)
하지만 둘 다 변화가 일어난 부분이 있다면, git은 어떤 것을 우선시해야 할지 판단하지 못하기 때문에 컨플릭트를 발생시킨다. (커밋 실패)
'개발 도구 > Git' 카테고리의 다른 글
| 누가 작업했는지 알고 싶을때(git blame, git show) (0) | 2022.12.01 |
|---|---|
| Remote Repository 내용을 merge하지 않고 가져오기(git fetch) (0) | 2022.11.30 |
| HEAD와 브랜치의 관계(개념, 원리) (0) | 2022.11.22 |
| 브랜치(branch)를 깃허브(github)에 push하기 (0) | 2022.11.21 |
| 머지 취소하기(git merge --abort) (0) | 2022.11.20 |
댓글