[Chapter 4] 복수의 repository로 협업(2) - rebase 3

 

 

 

꽤 어려운 과정을 진행하고 있습니다. 앞의 내용이 기억이 나지 않는다면, 앞의 rebase 과정을 다시 한번 살펴보고 오시기를 추천합니다. 이제 충돌 해결 과정을 통해서 rebase 기능에 대해서 살펴보도록 하겠습니다. 

 

 

[Chapter 4] 복수의 repository로 협업(2) - rebase 1

 

[Chapter 4] 복수의 repository로 협업(2) - rebase 2

 

 

---

 

 

우선 'rebase'라는 단어의 뜻을 한번 되짚어 보겠습니다. 여기서 re-base, 즉 '베이스'는 무엇을 의미할까요? 우리가 어떤 커밋을 생성했을 때, 해당 커밋이 특정 시점을 기준으로 작업되었다고 가정했을 때 '해당 시점을 베이스로 작업된 커밋'으로 표현할 수 있습니다. 

 

그럼 re-base라 함은, '베이스가 되는 커밋을 바꾼다'는 정도의 개념이 될 것입니다. 그럼 어떤 경우에 베이스가 되는 커밋을 바꾸게 되는 것일까요? 충돌 상황을 가정하고 예시를 들어서 설명해 보겠습니다. 

 

예를 들어 아래와 같이 NEWBIE에서 작업된 [커밋1]을 ME의 원격 저장소의 [커밋2]와 병합하려고 시도를 했는데, 충돌이 발생했습니다. 

 

이제 이를 해결하기 위해서 병합[커밋3]을 만들어서 충돌을 모두 해결한 다음, [커밋2]와 병합하게 된다면 충돌은 문제없이 해결됩니다. 하지만, 본질적으로 원래 수정이 발생한 커밋은 [커밋1]인데 수정을 위한 절차인 [커밋3]가 불필요하게 발생하였습니다. 이런 경우에 충돌과 해결을 위한 불필요한 과정을 제외하고 변동 사항만 깔끔하게 남길 수 있을까요?

 

물론 충돌 수정 과정도 남겨야하지 않나??라는 생각이 들 수도 있지만, 본질적으로 정상적인 수정 기록과 병합이 남겨져야 히스토리 리뷰에 집중할 수 있기 때문에 중간에 굳이 실수했던 혹은 충돌했던 커밋의 기록을 남겨두지 않는다는 것을 의도로 이해해 주시면 됩니다.

 

 

 

---

 

 

그렇다면 어떤 방식으로 rebase를 한다는 것일까요? 이번엔 아래의 상황을 보겠습니다. [커밋0]을 베이스로 하여 두 개의 저장소에서 각각 커밋이 이루어진 상태입니다. 같은 커밋을 베이스로 작업을 했기 때문에 동일한 라인에서 수정도 발생하고 추가가 이루어져서 [커밋3]과 [커밋1], [커밋2]와는 병합 과정에서 충돌이 발생합니다.

 

이때, 우리는 [커밋1]과 [커밋2]를 [커밋0]을 베이스로 만든 커밋이 아니라, [커밋3]을 베이스로 만든 커밋이라고 이력을 바꾸어 버릴 수 있습니다. 그럼 결국 [커밋3]과 [커밋2]를 합칠 수 있게 되죠. 심지어는 빨리 감기 병합이 되므로 더 간단해집니다. 

 

어?! 잠깐, 충돌이 원래 있지 않았냐구요? 이 충돌 과정 역시 rebase 과정에서 수정해 이력을 남기지 않고 자연스럽게 커밋이 이어지도록 만드는 것이 이번 과정의 목적입니다. 이를테면, 일종의 "이력 조작"인 것이죠. 

 

다음 아티클에서 우리의 실습용 원본 / 원격 저장소를 통해서 이러한 과정을 실제로 rebase 처리를 진행해 보겠습니다.