Github Merge 방식 이해하기

변현섭·2023년 7월 10일
3

Github 사용법

목록 보기
10/17

지난 포스팅에서 PR을 통해 Merge 하는 방법에 대해 배워보았습니다. 그러나 아직 어떤 방식으로 Merge 할지에 대해서는 이야기하지 않았는데요. 그래서 이번 포스팅에선 깃허브의 Merge 방식에 대해서 소개해보려 합니다.

1. Github Merge 방식

Github에서 제공하는 Merge 방식은 총 3가지로, Merge, Squash and Merge, Rebase and Merge가 있다. 이 중 어떠한 Merge 방식을 선택하느냐에 따라 커밋 히스토리가 천차만별로 달라질 수 있다. 각각의 방식은 어떠한 특징이 있으며, 어떤 상황에 유리한지 알아보자.

1) Merge

가장 기본적인 병합 방식으로, 병합되는 브랜치의 커밋 히스토리를 유지하면서 새로운 병합 커밋을 생성한다. 따라서 커밋 이력을 모두 남길 때 사용한다. 하지만, 두 브랜치의 변경 사항을 함께 포함하는 새로운 커밋이 생성되므로 커밋 히스토리가 복잡해질 수 있다. 이 방식은 다시 Fast-Forward 방식과 Recursive 방식으로 나뉜다.

① Fast-Forward 방식

  • 새로운 브랜치 my-branch가 main 브랜치로부터 분기된 이후 main 브랜치에 새로운 커밋이 올라오지 않았다면, my-branch가 main과 비교하여 최신의 브랜치라고 할 수 있다.
  • 이런 경우 my-branch의 변경 이력을 그대로 main 으로 가져올 수 있다.
  • 병합되는 브랜치가 다른 브랜치의 이력을 모두 포함하고 있는 경우에 사용된다.

② Recursive 방식

  • my-branch가 main 브랜치에서 분기되고, main 브랜치에 새로운 커밋이 생겼다면, my-branch를 최신으로 간주할 수 없다.
  • 따라서 my-branch 와 main 을 공통 부모로 한 새로운 Merge Commit을 생성하게된다.
  • 두 브랜치가 서로 다른 이력을 가지고 있는 경우에 사용된다.
  • Fast-Forward Merge가 가능한 상태에서 git merge 명령에 --no-ff 옵션을 주면 강제로 Merge Commit을 생성하게 할 수 있다.

2) Squash and Merge

Squash는 여러개의 커밋을 하나의 커밋으로 합치는 것을 의미한다. Squash Merge는 병합할 브랜치의 모든 커밋을 하나의 커밋으로 Squash(으깨다)한 새로운 커밋을 Base 브랜치에 추가하는 방식으로 병합하는 것을 의미한다.

이전의 커밋 히스토리를 간소화하여 깔끔하게 이력을 유지할 수 있으나, 단일 커밋으로 병합되기 때문에 브랜치 간의 변경 사항을 추적하기는 어렵다.

3) Rebase and Merge

Rebase를 알아보기 전에 Base가 무엇인지 알아보자. my-branch가 main 브랜치의 A 커밋에서 분기되었다고 하자. 이때, my-branch의 Base는 A 커밋이다. Rebase는 Base를 다시 설정한다는 의미를 갖고 있다. Rebase를 수행하면 my-branch 가 분기된 main 브랜치의 최신 커밋을 Base로 설정한다.

커밋 히스토리가 선형적으로 유지되어 깔끔하고 읽기 쉬운 이력을 유지할 수 있다는 점은 장점이지만, 이전의 커밋들을 변경하기 때문에 다른 개발자들이 해당 브랜치를 사용 중이라면, 주의가 필요하다.

2. 최적의 선택

깃허브의 Merge 방식을 완벽하게 이해하면 좋겠지만, 정확히 알지 못하더라도 큰 상관은 없다. 상황에 맞는 Merege 방식을 선택할 줄만 알아도 충분하다.

1) feature 브랜치에서 develop 브랜치로 merge 하는 경우

Squash and Merge가 유리하다. feature 브랜치에서 기능을 개발하기 위해 사용된 지저분한 커밋 내역을 하나의 커밋으로 묶어 develop에 병합함으로써, develop에는 기능 단위로 커밋이 추가되도록 정리할 수 있다. 또한 feature 브랜치는 develop 브랜치에 병합 후 제거되므로, Merge Commit을 굳이 남길 필요가 없다.

2) develop 브랜치에서 main 브랜치로 merge 하는 경우

Rebase and Merge가 유리하다. main 브랜치는 지금까지 작업한 모든 기능을 배포할 때 병합한다. develop 브랜치를 Squash and Merge 하게 되면 커밋 이력이 모두 사라져, 특정 기능에서 문제가 생겼을 때 롤백할 수 없게 된다. main 브랜치도 마찬가지로 Merge Commit은 남길 필요가 없다.

[이미지 출처]

profile
Java Spring, Android Kotlin, Node.js, ML/DL 개발을 공부하는 인하대학교 정보통신공학과 학생입니다.

0개의 댓글