HashiCorp의 공동 창업자인 Mitchell Hashimoto가 Git에서 Merge, Rebase, Squash에 관한 질문을 많으 받아서 Gist의 본인의 생각을 정리해서 올려주었습니다.(Mitchell Hashimoto는 이번에 HiashiCorp에서 물러났습니다.)

Merge, Rebase, Squash 중 하나가 좋다고 하는 것은 틀린 말이고 셋다 각각 필요한 상황이 따로 있다고 생각합니다. Mitchell은 Merge와 Merge 커밋을 남기는 것이 히스토리를 가장 잘 표현한다고 생각해서 Merge를 선호하는 편이고 모든 커밋을 빌드할 수 있게 유지한다면 커밋이 많을수록 bisect가 좋아진다고 합니다.

하나의 커밋에 변경이 많은 것을 싫어하고 한 커밋이 +50/-50 정도가 가장 좋으며 이렇게 하려면 모두가 규칙을 잘 따라합니다. 하지만 모두 규칙을 따르기가 쉽지 않기 때문에 오픈소스에서 하나의 PR에 WIP 커밋이 많은데 각 커밋의 차이가 작고 PR의 하나의 목표만 가지고 있다면 이때 Squash를 사용한다고 합니다. 그리고 Squash를 사용하더라고 Git/GitHub이 주는 기본 메시지를 친절하지 않아서 다시 작성하는 편이라고 합니다.

한 PR내에서 변경 사항이 많은 WIP 커밋이 많은 경우에는 rebase를 통해 스쿼시하고 순서도 조정해서 관리하고 있으며 최근에 50개 이상의 커밋을 대규모로 리베이스할 때는 GUI가 편하다는 걸 깨닫고 Tower 앱을 쓰고 있다고 합니다.

---------

추가로 제 생각을 덧붙이면 기본적으로 동의하는 편입니다. 원래 선호하는 것과 협업을 하면서 합의로 하기 위해 더 쉬운 규칙으로 바꿔나간 것이 포함되어 있습니다.

전 머지보다는 리베이스를 이용해서 커밋 라인이 일자로 되는걸 더 선호합니다. 머지와 머지 커밋이 있는 경우 해당 작업을 전체적으로 리버트하기가 편하기 때문에 예전에는 선호했었지만 머지할 때 리베이스 하지 않으면 머지의 커밋들이 이전 시간대에 남아있어서 오히려 전 파악하기 어려운 느낌이고 모든 PR이 다 머지커밋이 생기는 것도 히스토리를 지저분하게 만드는 경향이 있어서 그냥 일관되게 머지 커밋을 안만들고 있습니다.

과거에는 PR에서도 모든 커밋의 순서와 메시지를 중요하게 생각했기에 작업하면서 인터렉티브 리베이스로 순서도 계속 조정하고 비슷한 논리적 단위로 합쳐서 관리하는 것을 선호했습니다만 지금은 스쿼시를 훨씬더 선호합니다. 몇가지 이유가 있는데 PR을 올릴 때 Mitchell 얘기처럼 변경사항이 작은걸 선호하는데(기능을 하다가 리팩토링을 하거나 설정을 바꾸더라도 해당 커밋을 다른 PR로 분리하는 편입니다.) 여기서 커밋 히스토리까지 관리하는게 쉽지 않고 코드 리뷰때 이런 부분까지 맞춰야 한다는 걸 합의하기가 쉽지 않아서 그냥 PR의 커밋은 대충 올리고 스쿼시 머지할 때만 메시지를 정리하도록 하는게 더 편하기 때문입니다. (많은 사람이 git rebase에는 익숙하지 않다는 문제도 섞여 있습니다.)

그리고 인터렉티브 rebase로 히스토리 순서를 바꾸면 코드리뷰를 할때 오히려 동료들에게 불편함을 주었습니다. 예를 들어 함수 이름에 오타가 있어요 라고 하면 다음 커밋에서 오타 수정 커밋이 있으면 바로 해당 커밋만 눌러서 쉽게 확인할 수 있지만 이를 리베이스로 이전 커밋에 다시 합친다면 어떻게 바꾸었는지 확인하기가 어려워서 코드를 전체적으로 다시봐야하기 때문입니다. 이렇게 보니 PR에서는 리베이스는 하지만 인터렉티브 리베이스로 순서를 바꾸거나 커밋을 합치진 않습니다. 그렇다 보면 커밋에 불필요한 커밋이 많이 생기기 때문에 PR 머지전에 정리를 요구한다기 보다는 그냥 스쿼시로 하나의 커밋으로 합치고 하나의 PR이 너무 많은 변경 사항을 가지지 않도록 요구하는게 더 쉬운 정책이라고 생각했습니다.

https://gist.github.com/mitchellh/319019b1b8aac9110fcfb1862e0c97fb