git rebase 전략

우리 회사에서는 git rebase 전략을 사용한다. 무슨 전략인지, 이것을 왜 사용하는지 알아보고자 한다.

merge

merge는 하나의 브랜치와 다른 브랜치의 변경 이력 전체를 합치는 방법이다.

commit a, b, c를 refer하는 m이 생성되고 m을 통해 a + b + c가 master에 추가된다.

merge한 경우

github에서는 기본적으로 merge로 병합시키도록 한다.

$ git checkout master
$ git merge my-branch

 

squash

commit a + b + c를 합쳐서 새로운 commit, abc를 만들어지고 master에 추가된다.

commit a + b + c를 합쳐서 새로운 commit, abc를 만들어지고 master에 추가된다. abc는 1개의 parent를 가진다. feature 브랜치의 commit history를 합쳐서 깔끔하게 만들기 위해 사용한다.

sqash로 merge한 경우

이전에 내가 작성했던 커밋이 하위로 들어가게 된다.

squash로 merge하려고 한다면, 다음 버튼을 누르고 merge하면 된다.

$ git checkout master
$ git merge --squash my-branch
$ git commit -m "your-commit-message"

rebase

모든 커밋이 합쳐지지 않고 각각 root 브랜치에 추가된다.

Merge는 Merge commit 기록이 추가로 남게 되지만 Rebase의 경우에는 branch 병합 시 Merge commit 기록이 남지 않는다. 따라서 마치 하나의 브랜치에서 작업한 것처럼 보여진다.

$ git checkout my-branch
$ git rebase master
$ git checkout master
$ git merge my-branch

언제 어떤 전략을 써야할까?

[번역] merge vs rebase vs squash

[번역] merge vs rebase vs squash

위 레퍼런스에서는 각 전략마다 어떠한 특징이 있는지 정리한다. 해당 글에서는 각각의 전략마다 장점이 있고 상황에 따라 어떤 것을 사용하는게 좋은지 달라진다고 한다.

---

squash는 커밋이 합쳐져서 병합이 되기 때문에, 버그가 발생하면 해당 정보를 찾기 어렵다고 한다.

그러면 "아하, 여기에 버그가 있구나" 하고 바로 알 수 있죠. 스쿼시는 이 정보를 파괴합니다. 매일 하나씩 스쿼시 하기보다 저는 차라리 매일 1000개의 +50/-50 커밋을 머지하겠습니다.

커밋간 단위가 작고, 모두가 하나의 목표를 향하는 경우에는 스쿼시를 사용한다고 한다. 모두가 하나의 작업을 분담해서 한다면 squash를 통해 커밋이 이어져 보일 수 있기 때문이다.

PR에 수많은 작은 "WIP" "WIP" "WIP" 커밋이 있지만 총 diff가 작고 모두가 하나의 목표를 향하는 경우에는 스쿼시(squash)를 사용합니다.

주의할 점은 스쿼시를 할 때 커밋메세지에 충분한 설명을 담을 수 있도록 하는 것이다. 여러 작업이 뭉쳐있기 떄문이다.

저는 스쿼시를 하며 커밋 메세지를 다시 작성할 때 메세지에 충분히 설명이 담기도록 주의합니다. Git과 GitHub에서 자동으로 생성되는 기본 스쿼시 커밋 메세지는 좋지 않습니다.

---

회사에서는 rebase 전략에 모든 작업이 한 커밋으로 나갈 수 있도록 한다. 작업 단위가 크기 때문에 버그가 발생할 때 한 커밋만 revert하기 위함이다. 만약 한 feature에서 17개 commit을 만들고, main에 올라갔다고 하자.

만약 버그가 발생하면 17개 커밋 중 어떠한 커밋을 revert 해야하는지 찾기 어려울 것이다. 그렇기 때문에 작업의 흐름을 잘 파악하고, 커밋 관리가 쉽도록 rebase 전략을 사용하는 것 같다.

Reference

[GIT] Merge vs Rebase 차이

[Git] Merge 이해하기 (Merge / Squash and Merge / Rebase and Merge)