[Git] Git merge 전략 (merge, rebase merge, squash merge)

Git을 이용할 때, 히스토리를 관리하는 방법인데요.

평소에는 보통 혼자 개발을 진행했기 때문에, merge만 이용해서 feature로부터 develop 브랜치로 병합하는 형식으로 진행했었는데요.

 

하지만 여기에 merge를 하는 방법에도 여러가지가 존재합니다.

 

대표적으로 3가지의 전략이 있는데요.

merge, rebase and merge, squash and merge 이렇게 세 가지 입니다.

 

각각의 전략이 모두 특징을 가지는데 알고 사용하면 각 브랜치를 관리하는데 유용할 것이라 생각이 듭니다.

 

그렇다면 먼저 얘기하고 가야할 부분은 왜 굳이 이렇게 여러가지 방법을 알고 있어야할까요..?!

우선 커밋 히스토리 관리가 왜 중요한지를 알아야겠죠

 

 

커밋 히스토리(Commit History)

보통 개발자들이 작업을 진행할 때, 팀과의 컨벤션들을 정하는데요. 여기에 포함되는 것들은 코딩 컨벤션, 깃 전략, 커밋 메세지 작성법들이 되겠죠. 그렇다면 저희가 주목해야하는 것은 커밋 메세지 작성법이 되겠습니다.

 

왜 굳이 커밋 메세지 작성법에 대해 약속을 정하고 그 규칙을 지키게 할까요..?

아무래도 커밋 메세지를 보고 여기에선 어떤 내용이 변경되었는지 한 눈에 파악하기 위함이겠죠. 만약 어떤 커밋들을 살피는데 메세지가 중구난방으로 각각의 방식으로 작성되어 있다면, 어떤 내역을 살펴보러고하는데 커밋메세지가 눈에 들어오지 않기 때문에 모든 커밋을 눌러서 확인한다고 시간이 낭비되겠죠..?! 바로 이러한 상황을 맞이하고 싶지 않기 때문에 이렇게 약속을 정하게 됩니다.

 

그럼 이렇게 의미있는 커밋이력들이 모여서 형성하게 되는 것이 커밋 히스토리(Commit History)인데요.

우선 1차적으로 커밋을 의미 있게 작성했다면 필요한 커밋 이력을 찾기가 편해지겠죠. 그 다음으로 필요한 것이 이 커밋들이 모여서 이루는 커밋 히스토리(Commit History) 관리입니다.

 

만약 어떤 버그가 발생했습니다.

근데 release 3.0.0에선 없던 버그가 release 3.0.1에선 발생했습니다. 그렇다면 어디에서 그 버그에 관련된 내용을 찾을까요?

 

바로 커밋 히스토리로부터 관련된 버그의 수정 내역을 찾겠죠. 근데 이 때, 커밋 히스토리가 제대로 정리되어 있지 않고 복잡하게 남아있다면 찾는 시간도 오래걸리고 작업 효율이 나지 않겠죠! 이러한 상황을 위해서 커밋 히스토리(Commit History) 관리가 필요하게 됩니다.

 

그렇다면 이러한 커밋 히스토리(Commit History) 관리를 위한 3가지 방법에 대해 알아보도록 하겠습니다.

 

merge

가장 기본적인 방법입니다. 이 방법을 사용하면 merge에 대한 commit이 하나 생성되고 어느 시점에 merge를 진행했는지 쉽게 알 수 있습니다. 즉, develop에서 feature에 대해 merge를 진행하면 어느 시점에 feature가 develop으로 merge되었는지를 쉽게 확인할 수 있습니다.

이런식으로 feature/c, feature/d가 어느 시점에 develop으로 합쳐졌는지를 쉽게 알 수 있습니다. 

 

그렇지만 이 방법은 만약 feature 브랜치가 늘어나고 여러 번의 merge가 생기게 되면, 그래프가 복잡해져 커밋 히스토리(Commit History)를 파악하기 더욱 어려워질 수 있습니다. 하지만 merge의 시점은 확실히 알 수 있다는 장점이 있겠죠.

 

제 개인적인 생각으로는 이 방법은 release 브랜치에서 최종 버그들이 수정되고 master 브랜치로 합쳐질 때, 사용하면 병합 시점을 알 수 있어서 어떤 버그까지 픽스되고 안정이 되었는지 바로 알 수 있는 방법인 것 같습니다.

 

 

squash and merge

다음은 squash and merge 방법입니다. 이 방법은 merge에 대한 이력은 생기지 않는 방법입니다. 예를들어 feature에서 여러 작업을 하고 develop으로 합치는 경우에 feature 브랜치의 많은 작업 이력들을 하나의 커밋으로 합쳐서 develop으로 합칩니다.

이 그림을 보면 feature/c에서 작업한 3가지의 커밋이 별도로 develop으로 merge가 되는 형식이 아니고 세 가지의 커밋이 하나로 합쳐져서 develop 제일 앞의 부분에 commit으로 붙게 됩니다.

 

이러한 방법은 feature의 지저분한 작업 이력들을 develop으로 합칠 때 사용하면 develop의 이력들을 깔끔하게 관리할 수 있을 것 같습니다. 어차피 feature 브랜치들은 merge가 되면 삭제하잖아요~

 

 

rebase and merge

이번에는 rebase and merge 방법입니다. 이 방법은 역시 merge에 대한 이력이 남는 방법은 아닙니다. squash and merge와는 다르게 모든 커밋이력들이 rebase 되어서 붙는 방법입니다. 즉, fast-forward 됩니다. 

지금 그림은 feature/a의 커밋 이력들이 모두 develop으로 붙어진 그림입니다. 여기서 만약 feature/a 브랜치를 삭제하게 되면 develop 브랜치에서만 작업한 것 같은 그림이 나타나게 되겠죠~

 

다만 이 방법은 언제 merge가 되었는지를 알 수 없는 방법이긴합니다. 그렇지만 모든 커밋이력을 가지고 합칠 수 있다는 장점이 있겠죠. 

 

release -> master 브랜치로 합칠 때, 사용하면 모든 release에 대한 이력을 master에 자세하게 남길 수 있는 방법이 될 것 같습니다. 꼭 태깅을 해서 사용하는게 좋을 것 같습니다!

 

 

오늘은 이렇게 3가지의 커밋 히스토리(Commit History) 관리를 위한 방법을 알아보았는데요. 

각자의 상황에 맞게 사용하면 좋은 방법들이니 꼭 이 방법이 좋고 안좋다 이런 것은 없는 것 같습니다.

각 협업의 상황에 맞게 섞어서 활용하면 좋을 방법인 것 같습니다.

 

오늘도 도움이 되었으면 좋겠습니다 :)