이 글의 목적

최근 Github의 Branch 분기와 Pull request merge를 배우고 활용하면서 Merge의 종류가 다양하다는 걸 알게 되어 이번 포스팅에서 알아보려고 한다.

merge의 모든 속성을 알아볼 것은 아니고, Pull request를 할 때에 Github가 권장하는 merge 세 가지(merge, sqaush merge, rebase merge)에 대해 알아볼 것이다.

Pull request

Git으로 작업을 하면서, 어느 Branch에서 작업한 내용을 다른 Branch에 대한 Merge의 승인을 해줄 것을 요청하는 행위를 Pull request(이하 PR)라고 한다.

PR 요청을 받은 Repository의 관리자는 PR 내용을 보고 해당 Branch에 대한 Merge의 승인 여부를 정할 수 있다. 문제가 있다고 생각되면 PR을 반려할 수 있고, 문제가 없다고 판단되면 Merge를 승인하고, 해당 Branch에 PR commit code가 합쳐진다.

PR 요청이 승인 되어 Merge되면, PR 요청을 보낸 사람은 기여를 인정받아 해당 Repository의 Contributor가 된다. 명망있는 Repository의 Contributor가 되면 일종의 자기 증명이 가능하니 PR이 활발히 일어난다. 오픈 소스의 순 기능이라고 생각한다.

Pull request merge

Github 웹사이트에서 PR 요청을 승인해서 Merge하려고 할 때에, Github는 Merge에 대해 세 가지 선택지를 준다. 바로 Merge, Squash merge, Rebase merge이다.

Merge

Merge는 그냥 일반 Merge다. Branch와 Branch는 이어지고 Merge된 Repository의 History에서 어느 Branch에서 Merge되었는지, 이 Branch에서 어떤 Commit들이 있었는지 모두 볼 수 있다.

파란 게 develope branch고 노란 게 #8-Chat.vue/$socket.id branch다.
이 그래프는 develope에서 #8-Chat.vue/$socket.id을 merge했을 때의 그래프이다. #8-Chat.vue/$socket.id으로부터의 Pull request를 Merge했다는 설명이 명시되어 있고, branch도 이어져 있어서 그 사실을 직관적으로 알 수 있다.

• 이 방식의 장점
  Git history에서 해당 Pull request에 대해 상세하게 확인할 수 있다.
• 단점
  그러나 Branch가 많아지고, Commit도 많아지고 하면 Git history는 알아보기가 힘들어진다. 프로젝트의 규모가 크면 클 수록 이 방식은 선호되지 않는다.

Rebase merge

Rebase merge는 Merge할 Branch의 Commit 내역들을 그대로 옮긴다. Branch의 Base를 옮기는 일이니 말 그대로 Rebase다. 그래서 Branch는 이어지지 않는다.

초록색이 main, 분홍색이 1-Caht.vue/getCss다.
이 그래프는 main에서 1-Caht.vue/getCss의 Pull request를 Rebase and merge 했을 때의 그래프다.1-Caht.vue/getCss의 fix #1이라는 commit이 main의 fix #1 (#12)라는 이름의 commit으로 그대로 옮겨진 것이다. #1은 Issue link, (#12)는 Pull request의 번호다.
commit의 base를 1-Caht.vue/getCss에서 main으로 옮긴 것이기 때문에 branch는 이어져 있지 않다. 보통 이 이후에 rebase를 한 branch는 삭제해서 그래프를 깔끔하게 유지한다.

• 이 방식의 장점
  Git history를 볼 때 깔끔하게 볼 수 있다. 여러 개의 Branch가 복잡하게 얽혀있지 않고 그냥 default branch 하나의 Histroy만 쭉 읽으면 해당 프로젝트의 이력을 이해할 수 있다.
• 단점
  여러 개의 Commit을 Rebase merge했는데 Commit conflict가 일어나면 Merge하려는 모든 Commit에서 Conflict가 일어난다.
  생활코딩님의 rebase 충돌과 원인 해결 영상을 보면 좀 더 쉽게 이해할 수 있다.
  또한 거미줄처럼 이어지는 Branch는 사라지지만, 여전히 의미가 없다시피 하는 Commit도 History에 남는다.

Squash merge

사실 Squash는 Rebase merge의 Option이다. Squash 옵션을 적용한 Rebase merge를 Squash merge라고 부르는 모양이다.

Squash merge는 Rebase하되 Merge할 Commit들을 하나의 Commit으로 뭉친다. Squash는 사전적 의미로 으깨다, 짓누르다 라는 뜻을 가지고 있다.

develope로부터 분기한 16-ChatUiImprove가 있다. 16-ChatUiImprove에는 2개의 commit이 있다. 여기서 Squash merge를 사용해보겠다.

16-ChatUiImprove의 Commit들이 하나로 합쳐진 다음 develope로 rebase되었다. 자잘한 CSS 변경, 오타 수정 같은 Commit까지 History에 남기지 않고 의미 있는 Commit들으로만 History를 유지할 수게 된다.

• 이 방식의 장점
  Git history의 Branch도 깔끔하게 유지하되 자잘한 Commit들은 없애고 의미있는 Commit으로만 History를 이룰 수 있다.
• 단점
  나는 아직 이 방식의 단점을 느끼지 못 했다. 다른 사람들은 Merge에 대한 정보가 부족한 점을 단점으로 여기고 있으나, 해당 Merge Commit의 설명에 정보를 자세히 명시해놓으면 될 일이다.

🌞

이번 포스트에선 Merge의 종류에 대해 간략하게 알아보았다.
이 의외에도 Merge option은 굉장히 다양하다.

사실 1인 개발에 있어서는 그냥 main branch 하나 develope branch 하나면 충분하지만, 나는 미리미리 Git 협업에 익숙해지고 싶은 마음이기도 하고 1인 개발에서도 Issue tarcker와 Project board를 사용하면 개발이 좀 더 잘 되어서 기능 개발을 할 때마다 branch를 분기하고 PR을 하고 있다.

---

당초 취업을 생각하고 있던 것이 이번 년도의 초였는데, 벌써 매미 울음소리가 들려오는 계절이 왔다. 내 포트폴리오에 실린 프로젝트들은 그리 입맛이 당기지 않는 모양이다.

그것은 그렇다 하더라도 부산에는 정말 구인공고가 없다. 정말 빈손으로라도 서울으로 올라가야겠다는 생각이 점점 커진다. 답답한 나날이다. 구인공고가 없는 건 어쩔 수가 없는 일이고 공부는 계속해야하지 않겠는가.

그래서 React 말고도 Vue를 배우고 있다. 주니어일 때에는 T자 모양으로 기술 스택을 관리하라는 모양이다. 한 언어를 깊게 파는 것도 좋으나, 다른 언어도 기본적인 부분 정도는 배워서 지원할 수 있는 회사의 범위를 넓히고 식견도 넓히라는 이야기다.

아무튼 그렇다. 어서 취업이 하고 싶은 마음이다.