작업이 완료된 토픽 브랜치는 최종적으로 통합 브랜치에 병합됩니다. 브랜치 통합에는 merge 를 사용하는 방법과 'rebase'를 사용하는 방법의 2가지 종류가 있습니다. 어느 쪽을 사용하느냐에 따라 통합 후의 브랜치의 이력이 크게 달라집니다.

1. merge

• merge를 사용하면, 여러 개의 브랜치를 하나로 모을 수 있습니다.

1. 예를 들어, 아래 그림과 같이 'master' 브랜치에서 분기하는 'bugfix' 라는 브랜치가 있다고 가정해 보시다.

   

2. 이 'bugfix' 브랜치를 'master' 브랜치로 병합할 때, 'master' 브랜치의 상태가 이전부터 변경되어 있지만 않으면 매우 쉽게 병합할 수 있습니다.

   'bugfix' 브랜치의 이력은 'master' 브랜치의 이력을 모두 포함하고 있기 때문에, 'master' 브랜치는 단순히 이동하기만 해도 'bugfix' 브랜치의 내용을 적용할 수 있습니다. 또한 이 같은 병합은 'fast-forward(빨리 감기) 병합' 이라고 부릅니다.

   

3. 하지만 'bugfix' 브랜치를 분기한 이후에 'master' 브랜치에 여러 가지 변경 사항이 적용되는 경우도 있습니다. 이 경우에는 'master' 브랜치 내의 변경 내용과 'bugfix' 브랜치 내의 변경 내용을 하나로 통합할 필요가 있습니다.

   

4. 따라서 양쪽의 변경을 가져온 'merge commit(병합 커밋)' 을 실행하게 됩니다. 병합 완료 후, 통합 브랜치인 'master' 브랜치로 통합된 이력이 아래 그림과 같이 생기게 됩니다.

   

   → 병합 시 'master' 브랜치로 checkout 한 다음 'bugfix' 브랜치와 병합 실행

   ⚠️ 병합 실행 시에 'fast-forward 병합'이 가능한 경우라도 'non fast-forward 병합' 옵션을 지정하여 아래 그림과 같이 만들어 낼 수도 있습니다.

   'non fast-forward 병합' 을 실행하면, 브랜치가 그대로 남기 때문에 그 브랜치로 실행한 작업 확인 및 브랜치 관리 면에서 더 유용할 수 있습니다

   

2. rebase

• 위와 마찬가지로, 'master' 브랜치에서 분기하는 'bugfix' 브랜치가 있다고 가정합니다.

  

  이제 rebase 를 이용해 어떻게 브랜치를 통합할 수 있는지 알아볼 차례 입니다. 아래 그림과 같이 'non fast-forward 병합' 방식으로 진행되는 시나리오를 만들어 봅시다.

  

  1. 우선 'bugfix' 브랜치를 'master' 브랜치에 rebase 하면, 'bugfix' 브랜치의 이력이 'master' 브랜치 뒤로 이동하게 됩니다. 그 때문에 그림과 같이 이력이 하나의 줄기로 이어지게 됩니다. 이 때 이동하는 커밋 X와 Y 내에 포함되는 내용이 'master' 의 커밋된 버전들과 퉁돌하는 부분이 생길 수 있습니다. 그 때는 각각의 커밋에서 발생한 충돌 내용을 수정할 필요가 있습니다.

     

  2. 'rebase'만 하면 아래 그림에서와 같이 'master' 의 위치는 그대로 유지됩니다. 'master' 브랜치의 위치를 변경하기 위해서는 'master' 브랜치에서 'bugfix' 브랜치를 fast-forward(빨리감기) 병합 하면 됩니다.

     

  ⚠️ merge 와 rebase 는 통합 브랜치에 토픽 브랜치를 통합하고자 하는 목적은 같으나, 그 특징은 약간 다릅니다.

  → merge : 변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡해짐

  → rebase : 이력은 단순해지지만, 원래의 커밋 이력이 변경됨. 정확한 이력을 남겨야 할 필요가 있을 경우에는 사용하면 안됨.

  merge 와 rebase 는 팀 운용 방침에 따라 구별해 쓸 수 있습니다.

  예를 들어 이력을 하나로 모두 모아서 처리하도록 운영한다고 치면 아래와 같이 구별해 사용할 수 있습니다.

  → 토픽 브랜치에 통합 브랜치의 최신 코드를 적용할 경우에는 rebase를 사용

  → 통합 브랜치에 토픽 브랜치를 불러올 경우에는 우선 rebase 를 한 후 merge