프로젝트를 시작하며(merge 전략)

이번에 스터디에서 프로젝트를 하나 하기로 했다. 주제는 1인 가구를 위한 쇼핑몰로 최근 4개월간 자바, 스프링, 객체지향에 대해서 기초부터 공부한 후 처음으로 하는 프로젝트이다. 처음으로 제대로 하는 프로젝트이다 보니 내가 알고있는 것들을 최대한 담아서 진행하고 싶은 마음이다. 

이런 마음으로 프로젝트를 시작하기에 앞서 git merge 전략과 branch 전략에 대해서 알아봤다.

 

git merge 전략

git merge 전략에는 다음과 같이 3개의 머지 전략이 있다.

• 일반 merge
• rebase and merge
• squash and merge

일반 merge

각각에 대해서 살펴보면 일반 merge의 경우 다음 그림과 같이 표현할 수 있는데, merge를 하기 전 브랜치에서 했던 작업들의 커밋 내용과, 해당 브랜치와 merge됐다는 기록이 모두 merge된 브랜치 내에 남게 된다.

장점은
merge된 브랜치가 삭제되어 사라져도 history에는 그대로 남아있어서 어떤 브랜치에서 어떻게 merge가 되었는지 파악이 가능하다는 것이고,

그로 인한 단점은
자잘한 commit들이 있을 때 그런 commit들의 기록조차 남아서 가독성이 떨어질 수 있고, 브랜치가 여러개로 나눠진 경우도 마찬가지로 가독성을 떨어뜨린다.

 

rebase and merge

rebase and merge인 경우 해당 브랜치의 base를 새롭게 설정하고 merge를 하는 방식인데, rebase를 통해 해당 branch에서 했던 작업들이 원래는 rebase한 브랜치에서 했던 작업처럼 보이게 하고 merge를 하는 것이다.

그림으로 설명하자면 다음과 같다. 

장점은
commit 히스토리를 단순하게 만들어준다.
rebase의 경우 브랜치를 병합할 때 merge commit의 기록이 남지 않아서 마치 하나의 브랜치에서 작업한 것처럼 보여진다.
작업 내역을 그대로 살려서 타겟 브랜치에 병합시키기 때문에 commit에 대한 정보를 알 수 있다.

단점은
merge commit이 남지 않기 때문에 병합시킨 브랜치가 언제 병합되었는지의 시점을 알 수 없다.
그리고 Merge Confilct이 발생했을 경우 각각의 commit에 충돌이 발생해서..
merge할 브랜치의 commit 내용이 많다면 조심해야한다.

 

squash and merge

squash and merge인 경우 squash를 통해 해당 브랜치에서 했던 작업들의 커밋 내용을 하나로 합치고 merge를 하는 방법을 말한다. 이렇게 하면은 합쳐진 브랜치에는 어떠한 브랜치와 merge가 이루어졌는지 알 수 있고 해당 브랜치에서 했던 commit들은 남지 않게 된다.

 

장점은
merge commit이 남아서 merge된 브랜치가 있었다는 것을 히스토리에서 알아볼 수 있고,
버전 별로 어떤 것이 변경되었는지 한 눈에 알 수 있다.
또한 merge된 브랜치의 변경 내역을 하나의 commit으로 합쳐서 병합시켰기 때문에 해당 브랜치에 있었던
자잘한 commit 내용이 가독성을 떨어뜨리는 일이 없다.

단점은
merge된 브랜치의 변경 내역이 하나의 commit으로만 남기 때문에 어떠한 과정으로 변경되었는지에 대한
정보를 알 수 없다.

 

위와 같이 3가지의 전략이 있는데 내가 하는 프로젝트에서는 rebase and merge를 이용하기로 했다. 이유는 위에 설명된 바와 같이, 하나의 브랜치에서 작업이 이루어진것 처럼 보여 가독성 좋은 커밋 히스토리를 볼 수 있고, squash 같은 경우에는 작업한 커밋 내역들이 보여지지 않아 어떠한 작업을 했는지 알 수 없어 보기 불편하다고 생각이 들었기에 rebase and merge 전략을 선택했다.

 

프로젝트를 시작하기에 앞서 이러한 전략을 처음 겪어보기에 설레는 마음도 있지만 프로젝트를 진행하다보면 충돌이 발생하는 상황이 나올수도 있을텐데 이를 잘 해결할 수 있을지에 대한 걱정도 된다. 뒤에 branch 전략을 이어서 포스팅 하겠다.